perm filename MSG.MSG[FTL,LSP] blob
sn#826887 filedate 1986-10-27 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00122 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00011 00002
C00012 00003 ∂03-Dec-84 0800 JK
C00013 00004 ∂18-Dec-84 1142 SCHERLIS@CMU-CS-C.ARPA kermit for Perq
C00014 00005 What to do next ----
C00016 00006 ∂16-Jan-85 1453 GOTELLI@SU-SCORE.ARPA Lucid users
C00017 00007 ∂17-Jan-85 1226 @MIT-MC:BROOKS@MIT-OZ
C00019 00008 ∂20-Jan-85 2011 SCHERLIS@CMU-CS-C.ARPA reader testing
C00023 00009 ∂26-Jan-85 1535 JK
C00025 00010 ∂30-Jan-85 1507 FTL Reader files delivered
C00028 00011 Bill---
C00032 00012 How is the compiler doing?
C00035 00013 ∂02-Feb-85 0836 JK
C00036 00014 ∂02-Feb-85 1149 @MIT-MC:BROOKS@MIT-OZ
C00039 00015 ∂02-Feb-85 1206 @MIT-MC:BROOKS@MIT-OZ
C00040 00016 Bill ---
C00045 00017 ∂04-Feb-85 0832 JK compiler status
C00048 00018
C00050 00019 ∂08-Feb-85 0841 @MIT-MC:BROOKS@MIT-OZ End march trip
C00051 00020 ∂08-Feb-85 2231 ROD for EB
C00055 00021 ∂10-Feb-85 0825 ROD losing let value bug
C00057 00022 ∂10-Feb-85 2151 ROD compiler status
C00065 00023 ∂11-Feb-85 1816 ROD (if (progn... bug
C00066 00024 ∂10-Feb-85 1302 JK New reader
C00078 00025 ∂12-Feb-85 2128 @MIT-MC:BROOKS@MIT-OZ Re: compiler and macros
C00080 00026 ∂13-Feb-85 2030 @MIT-MC:BROOKS@MIT-OZ defmacro in the same file bug.
C00085 00027 ∂15-Feb-85 0814 JK Re: jobs
C00087 00028 Rod ---
C00090 00029 ∂17-Feb-85 0425 @MIT-MC:BROOKS@MIT-OZ
C00092 00030 Rod ----
C00093 00031 Bill ---
C00094 00032 ∂17-Feb-85 2113 ROD adjust-stack bug
C00095 00033 ∂18-Feb-85 0823 JK tape
C00098 00034 ∂18-Feb-85 2133 EB
C00100 00035 ∂18-Feb-85 2031 SCHERLIS@CMU-CS-C.ARPA travel
C00103 00036 ∂19-Feb-85 0853 JK
C00105 00037 ∂20-Feb-85 0739 JK tape
C00107 00038 ∂20-Feb-85 0757 SCHERLIS@CMU-CS-C.ARPA Re: travel
C00109 00039 ∂21-Feb-85 0733 JK ["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>: Kyoto Common Lisp]
C00114 00040 ∂22-Feb-85 1819 JK trip to Lucid
C00116 00041 ∂26-Feb-85 1027 FTL
C00117 00042 ∂26-Feb-85 2015 @MIT-MC:BROOKS@MIT-OZ
C00119 00043 ∂02-Mar-85 1754 JK Reader
C00121 00044 ∂03-Mar-85 0936 JK compiler
C00122 00045 ∂04-Mar-85 1107 JK status, hint and query.
C00126 00046 How's closures? RPG tells me he told you all that you ever need to
C00127 00047 ∂06-Mar-85 1915 @MIT-MC:BROOKS@MIT-OZ
C00131 00048 ∂10-Mar-85 0755 JK
C00133 00049 ∂11-Mar-85 0841 JK 68020
C00135 00050 ∂11-Mar-85 0843 JK tape
C00138 00051 ∂13-Mar-85 0758 JK status
C00141 00052 ∂18-Mar-85 0716 JK tape
C00146 00053 ∂23-Mar-85 1144 JK
C00148 00054 ∂26-Mar-85 0843 JK For your info...
C00151 00055 ∂02-Apr-85 0800 JK flavor ?s
C00155 00056 ∂02-Apr-85 0801 JK this is a test
C00157 00057 ∂03-Apr-85 2026 JK
C00159 00058 ∂08-Apr-85 0822 JK tape
C00161 00059 ∂12-Apr-85 0743 JK Announcement
C00163 00060 ∂15-Apr-85 0721 JK
C00164 00061 ∂16-Apr-85 0844 JK misc questions
C00167 00062 ∂22-Apr-85 0749 JK
C00169 00063 ∂23-Apr-85 0810 JK closures
C00171 00064 ∂23-Apr-85 0811 JK
C00172 00065 ∂23-Apr-85 1938 JK
C00174 00066 ∂24-Apr-85 0743 JK
C00175 00067 ∂26-Apr-85 0738 JK 370 common lisp
C00177 00068 ∂29-Apr-85 0759 JK
C00178 00069 ∂29-Apr-85 0759 JK
C00181 00070 ∂29-Apr-85 0801 JK
C00183 00071 ∂29-Apr-85 0801 JK Re: Well
C00185 00072 ∂29-Apr-85 0803 JK
C00188 00073 ∂30-Apr-85 0818 JK
C00190 00074 ∂30-Apr-85 1646 JK
C00191 00075 ∂30-Apr-85 1653 JK Lucid and LISP programming
C00193 00076 ∂30-Apr-85 1654 JK Lucid & Lisp
C00201 00077 ∂30-Apr-85 1659 JK Lucid & Lisp
C00203 00078 ∂01-May-85 0754 JK Re: analyze-primop
C00205 00079 ∂03-May-85 0831 JK 370 CL
C00209 00080 ∂03-May-85 0831 JK gold hill
C00210 00081 ∂03-May-85 0832 JK generic arithmetic
C00215 00082 ∂03-May-85 0833 JK More arithmetic
C00220 00083 ∂03-May-85 0835 JK GCs
C00222 00084 ∂06-May-85 1028 JK tape
C00225 00085 ∂06-May-85 1032 JK Re: some to be done's
C00227 00086 ∂06-May-85 1033 JK
C00228 00087 ∂06-May-85 1040 JK Re: some to be done's
C00231 00088 ∂06-May-85 1040 JK CL bogosity
C00237 00089 ∂07-May-85 1437 JK
C00238 00090 ∂07-May-85 1438 JK
C00241 00091 ∂07-May-85 1900 JK
C00242 00092 ∂07-May-85 1900 JK trip
C00243 00093 ∂07-May-85 2002 JK Re: compiler bug
C00245 00094 ∂08-May-85 0749 JK Re: compiler bugs
C00247 00095 ∂09-May-85 0656 JK [Guy Steele <gls%AQUINAS@THINK.ARPA>: Macros -> declarations]
C00251 00096 ∂16-May-86 0807 JK olin shivers
C00256 00097 ∂23-May-85 1612 JK
C00258 00098 ∂23-May-85 1613 JK
C00259 00099 ∂23-May-85 1619 JK compiler
C00260 00100 ∂07-Jun-85 1515 JK summer jobs
C00271 00101 ∂11-Jun-85 1758 JK
C00273 00102 ∂13-Jun-85 0746 JK
C00276 00103 ∂13-Jun-85 0750 JK declaration pervasiveness.
C00281 00104 ∂13-Jun-85 0751 JK
C00282 00105 ∂17-Jun-85 0807 JK
C00284 00106 ∂21-Jun-85 0951 JK tape
C00286 00107 ∂23-Jun-85 0912 JK
C00288 00108 ∂27-Jun-85 0802 JK
C00291 00109 ∂30-Jun-85 0940 JK
C00294 00110 ∂07-Jul-85 1232 JK
C00296 00111 ∂15-Jul-85 0746 JK flavors
C00301 00112 ∂16-Jul-85 1303 F.DUFFIE@SU-GSB-WHY.ARPA Re: TeX index macros
C00303 00113 ∂17-Jul-85 1639 F.DUFFIE@SU-GSB-WHY.ARPA TeXmacros to Virginia Kean
C00308 00114 ∂17-Jul-85 1754 F.DUFFIE@SU-GSB-WHY.ARPA Re: index macros
C00309 00115 ∂25-Jul-85 0849 F.DUFFIE@SU-GSB-WHY.ARPA doublecolumns macro
C00312 00116 ∂25-Jul-85 0851 F.DUFFIE@SU-GSB-WHY.ARPA the files
C00321 00117 ∂26-Jul-85 1025 F.DUFFIE@SU-GSB-WHY.ARPA Re: index
C00323 00118 ∂26-Jul-85 1111 SCHERLIS@CMU-CS-C.ARPA Re: Lucid manual
C00325 00119 ∂02-Aug-85 0702 SCHERLIS@CMU-CS-C.ARPA documentation notes
C00326 00120 ∂03-Aug-85 1538 SCHERLIS@CMU-CS-C.ARPA First installment of COMMENTS
C00342 00121 ∂07-Aug-85 0848 F.DUFFIE@SU-GSB-WHY.ARPA Fonts to Virginia Kean
C00350 00122 ∂24-Oct-86 1619 edsel!bhopal!lgd@navajo.stanford.edu concepts.tex
C00389 ENDMK
C⊗;
∂03-Dec-84 0800 JK
∂02-Dec-84 2004 ROD lap spec
To: EJG, JK
New RODIMP.TXT[1,FTL] has the LAP specification chapter included.
∂18-Dec-84 1142 SCHERLIS@CMU-CS-C.ARPA kermit for Perq
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 Dec 84 11:41:48 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Tue 18 Dec 84 14:42:17-EST
Date: Tue 18 Dec 84 14:42:16-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: kermit for Perq
To: ftl@SU-AI.ARPA
I don't know if there is interest, but here is how to get Kermit for
the Perq: FTP (user anonymous) from CU20B (Columbia) the files
KER:PQ*.PAS
The Kermit "coordinator" there is SY.FDC@CU20B
Bill
-------
What to do next ----
Discussed the issue this morning with RPG, EJG and EB.
It seems that the prioritized list of tasks for you to do are:
Ongoing: Bugfixes and maintenance of the compiler.
(1) Fixing correct handling of tail recursion with an intervening let.
(2) Handling of lambda keywords.
(3) Extended functionality. Closures, multiple value handling etc.
(4) Correctness: Writing enough test cases to ensure that each part of the
code has been exercised. The test cases should be runnable
automatically so as to ensure easy re-testing.
Our current policy is to add a test case every time
we see a bug. There are directories like bug-report and test
under the current compiler.
(5) Performance tuning.
JK
∂16-Jan-85 1453 GOTELLI@SU-SCORE.ARPA Lucid users
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 16 Jan 85 14:53:10 PST
Date: Wed 16 Jan 85 14:49:53-PST
From: Lynn Gotelli <GOTELLI@SU-SCORE.ARPA>
Subject: Lucid users
To: FTL@SU-AI.ARPA
cc: ME@SU-AI.ARPA, gotelli@SU-SCORE.ARPA
Dick, Marty has asked me to charge <EB> Eric Benson and
<JLW> Jon White to Lucid. I have made these changes effective
1/1/85.
Lynn
-------
∂17-Jan-85 1226 @MIT-MC:BROOKS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Jan 85 12:26:15 PST
Date: Thu 17 Jan 85 15:19:05-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Tue 15 Jan 85 11:18:00-EST
Can you give me some feedback on the following:
(defun foo (a b) (print a) (bar b a)) can re-use the current frame
of foo for bar. (If bar were foo then we'd say this was tail recursion.)
If its a straightforward extension of correct tail recursion analysis
(which I'm sure it is) then should I make the compiler do this? The
disadvantage is in debugging an intervening frame has disappeared,
but it saves a lot of useless stack unwinding.
Rod
-------
∂20-Jan-85 2011 SCHERLIS@CMU-CS-C.ARPA reader testing
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Jan 85 20:10:59 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Sun 20 Jan 85 23:03:34-EST
Date: Sun 20 Jan 85 23:03:32-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: reader testing
To: jk@SU-AI.ARPA
Jussi --
I am about to start testing some parts of the reader, but I
need some code from you guys. Eric Benson, I think, has a definition
somewhere of a SELECT macro that works just like case except it
attempts expansion-time evaluation of the case branch tests. Thus,
if I have
(defconstant foo 1)
(defconstant bar 2)
(defconstant quux 3)
I could write something like
(select mumble
(foo ...)
((bar quux) ...)
(t ...))
and it will expand into something reasonable. (The CL case will not
allow this kind of use of constants.)
Of course, if nobody has a definition I could write one, but
it would be more sensible for us to standardize the few auxiliary
macros we use.
By the way, the tokenizer needs fast versions of the following
functions:
read-char
unread-char
upcase-char (a fast version that assumes a char is given)
In all cases, I do EOF testing by calling
(read-char stream nil nil).
I hope all is well with the Lucid folks.
Bill
-------
Can you send your code and spec to ftl asap? We would like to review it.
As for testing, as much of it as possible should be in runnable
automatically: We have special forms test and etest that do the
following:
(test <form> <name -- this is a string>)
does nothing if forms evaluates to t. Otherwise; if an error occurs or
form evaluates to nil, it prints a message to *error-output* mentioning
that the test with the given name failed.
(etest <form> <name>)
does the precisely the reverse --- it complains if no error occurred.
I have asked benson to send you the select macro.
∂26-Jan-85 1535 JK
∂26-Jan-85 1324 ROD keywords
To: RPG, JK
Well, I'm still hacking on getting keywords all done right. There's
an awful lot of code to get all the cases optimal--e.g. alpha is
already 50% bigger and growing.
There's a lot of weird checking that could be done at runtime
because of &allow-other-keys and :allow-other-keys. I'm doing all the
checking possible at compile time on that stuff, but sometimes
you just can't tell until runtime. Rather than slow down the
runtime I'm leaving out that error checking--that falls within the
Common Lisp definition, because the manual just says ``it is an error''.
However I want to check with you guys that runtime speed over runtime error
checks is the correct policy--I believe it will be a significant
slowdown for almost never errors the other way. The interpreter should
do all the checking however.
(I knew leaving keywords out of TAIL was a good idea....)
--------------
Rod ---- I have written and debugged a lambda list parser that returns
a horrid data structure handling all the wierd cases: May be that might
help --- I will send it to you monday.
JK
∂30-Jan-85 1507 FTL Reader files delivered
∂29-Jan-85 2139 SCHERLIS@CMU-CS-C.ARPA Reader files delivered
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 29 Jan 85 21:38:56 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Wed 30 Jan 85 00:40:18-EST
Date: Wed 30 Jan 85 00:40:13-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: Reader files delivered
To: jk@SU-AI.ARPA
Jussi --
There are now a bunch of READER files in [1,ftl]. Here is
the list (totaling about 80 pages):
RSPEC.TXT The specification document. (33pp)
RINIT.LSP A small file to load the reader stuff (for Perqs). (1p)
RDECL.LSP Declarations and DEFCONSTANTs. (5pp)
R.LSP The main reader body (only an init routine right now). (3pp)
R1.LSP Read buffer stuff. (3pp)
R2.LSP Readtable stuff. (10pp)
R3.LSP Character classification. (3pp)
R4.LSP The moby FSM. (21pp)
R5.LSP Dummy object constructors. (1p)
RTEST.LSP A function to help test read-token. (1p)
Notes:
(0) This includes the buffering, readtable management, character
classification, and read-token. I think this represents about 75% of
the reader, but is without question the most difficult part of the code.
The really hairy part -- READ-TOKEN -- is done and survives my random
testing. See RSPEC for details concerning what's there and what's
not. Don't try to read the FSM without having a go first at RPSEC!
(I also use Eric Benson's SELECT, which I didn't send.)
Bill---
Thanks for the files --- I have made a preliminary pass thru it; looks
good. I expect to get the other stuff you mentioned below in the
time schedule you mentioned:
------
-- real object constructors (integer, flonum, rational, symbol)
-- reader tails (for lists, quote, etc.)
-- read itself.
-- sharpm.
-- backq.
I'll have the first three of these in a week -- they're all quite
simple. Backq will then follow, with Sharpm coming last.
------
All in all, I would like everything done by the time you get here so that
you can start running it through the compiler. So far as I know, you will
be here in the middle of february.
I will read the stuff more thoroughly over the weekend . I will probably
send some more comments then.
(2) A formal test set will arrive shortly. How do you trap errors for
etest? Also, could you send me exact syntax for the test forms....
******
We have a with-error-trapping primitive in our system.
In spice, it maps into errset.
Syntax: (test <form> <name-string>)
complains if form causes an error or returns nil
(etest <form> <name-string>)
complains if form causes no errors.
(4) I haven't yet tried to compile the thing yet. Could you send me
some advice on Lucid conventions organizing declarations, etc...
Right now, they are all in a separate file, but separate compilation
isn't feasible due to the multitude of INLINE functions.
*******
Let's do this one when you get here.
(5) All error messages go through READER-FATAL-ERROR, READER-CERROR,
and (alas) READER-INTERNAL-ERROR on R4.LSP/2P. I will write better
messages when I see some standards. (The "LUCID: " prefix is there
to distinguish my messages from Spice messages!)
*******
I doubt that we will ever have a error message standard ---- the variety
of error situations is enormous.
However, we have agreed that all error messages should be listed in the spec.
You should do this.
(By the way, could we create a sub directory of FTL for the purpose of
buffering files on the way to and from Lucid? There are zillions
of files in [1,ftl] and it is easy to lose things.)
*******
I have deleted almost all of the files in ftl --- there is only 3 left.
How is the compiler doing?
We are currently finishing up on stage 2, which means that we have most of the
macro and error handling stuff done. Plus, Mcdonald has a very nice interrupt
handler and RPG is getting the GC to work.
We expect to do a lot of compiling the coming week --- if there is a new version
of the compiler, would appreciate getting it.
Next stage contains EVAL and redone LAP, among other things. We are currently
entertaining the proposal of really hacking our brains out and trying to
finish ahead of schedule. This way, we could control a larger share of the
company and really win big in the market place. It seems that a lot of the
stuff to be done in later stages has already been done in some form.
Which brings me back to the compiler: I sent you a list of goals that I am
including below.
Ongoing: Bugfixes and maintenance of the compiler.
(1) Fixing correct handling of tail recursion with an intervening let.
(2) Handling of lambda keywords.
(3) Extended functionality. Closures, multiple value handling etc.
(4) Correctness: Writing enough test cases to ensure that each part of the
code has been exercised. The test cases should be runnable
automatically so as to ensure easy re-testing.
Our current policy is to add a test case every time
we see a bug. There are directories like bug-report and test
under the current compiler.
(5) Performance tuning.
I would like to add another one: Nativizing the compiler to the Lucid
environment.
I would like to get a general idea what your schedule looks like vis-a-vis
these goals and possible visits to Lucid. I think it would be extremely
important to schedule significantly long visits to Lucid during the next
few months. Of course, Lucid would pay.
JK
∂02-Feb-85 0836 JK
∂02-Feb-85 0018 RPG GC progress
The low-level primitives seem to be pretty much under control - I got a
variant of the main loop of the GC to scan a segment and parse all of the
objects linearly, printing them out along with information about the
headers and all that. This tool, by the way, looks like it will be useful
for helping analyze memory usage. I saw all sorts of interesting layout
patterns when I scanned the static segment.
-rpg-
∂02-Feb-85 1149 @MIT-MC:BROOKS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Feb 85 11:49:24 PST
Date: Sat 2 Feb 85 14:52:06-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Sat 2 Feb 85 09:29:00-EST
I have completed (1) Fixing correct handling of tail recursion (it turned out
there were lots of other cases it dodn't do the right thing, like when
there are optional args--that's all fixed), and as a side effect I also
cleaned up the let optimizer and made it significantly better.
I am finishing (2) keywords today and tomorrow--it was much longer than
I expected. I will send you a tape Monday with about 1000 new lines of
code.
By nativizing the compiler, do you mean getting it to run in Lucille?
I could perhaps manage a week long visit at the end of March under the
following arrangement: I pay for my airfare out of research money--it
will be at the tail end of research related visits, while Lucid pays
for Nui's airfare--since it will include a Saturday night, and the
way the fare wars are going that would probably be quite cheap. We
would stay at chez RPG I presume.
I will start on closures the coming week (item (3) in your list).
Rod
-------
∂02-Feb-85 1206 @MIT-MC:BROOKS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Feb 85 12:06:26 PST
Date: Sat 2 Feb 85 15:08:56-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Sat 2 Feb 85 09:29:00-EST
That may be actually only 5 days I can be there in late March. I'll check
my calender on Monday and let you know for sure
From late may I will not have any teaching commitments and will be much
freer.
-------
Bill ---
Here are the error macros. They may be a little strange since our file
transfer mechanism to sail did not work out too well in this case and I had
to patch them up by hand.
I read through your code and documentation --
looks good. I wrote my comments up; Jan will send them tomorrow.
I thought some more about the next job for you --- EB tells me that
the printer interacts in all kinds of interesting ways with the rest
of the system. If you are not going to be physically around Lucid that
much, it might be more advisable to do a more independent module, like
the rest of TYPES module (subtypep and coerce).
This have the additional advantage of getting you
acquainted with the wonders of the Common Lisp type system.
JK
;;;; TEST -*- Mode:Lisp -*-
;;; ***************************************************************************
;;;
;;; (c) Copyright 1984 by Lucid, Inc.
;;;
;;; ***************************************************************************
(defmacro with-error-trapping (form)
(let ((,value ,form)) (values ,value t "" nil)))
(setq *inform* t)
;;; The test macro takes a form and a test name as a string.
;;; It prints an error message to *error-output* if an error
;;; is encountered or if the form returned nil.
(setq *inform* t)
(defmacro test (form test-name)
(let ((value (gensym))
(flag (gensym))
(message (gensym))
(funame (gensym)))
`(errset
(progn
(when *inform* (format *query-io* "%running ~s" ,test-name))
(multiple-value-bind
(,value ,flag ,message ,funame)
(with-error-trapping ,form)
(cond ((null ,flag)
(format *error-output*
"~%error occurred during evaluation of ~S with message:~%~S~%"
,test-name
,message))
((null ,value)
(format *error-output*
"~%error occurred during evaluation of ~s: ~% the form ~s returned nil"
,test-name
`,form)) )) )))))
;;; The etest macro takes a form and a test name as a string.
(defmacro etest (form test-name)
(let ((value (gensym))
(flag (gensym))
(message (gensym))
(funame (gensym)))
` (progn
(and *inform* (format *query-io* "~%running ~s~%" ,test-name))
(multiple-value-bind
(,value ,flag ,message ,funame)
(with-error-trapping (errset ,form ,t))
(cond ( ,value
(format *error-output*
"~%no error occurred during evaluation of ~S~%,or it returned t --- gasp~%"
,test-name))
(t (when *inform* (format *query-io*
"successfully produced error: ~S~%"
,message))))))))
∂04-Feb-85 0832 JK compiler status
∂03-Feb-85 2200 @MIT-MC:BROOKS@MIT-OZ compiler status
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Feb 85 21:59:47 PST
Date: Mon 4 Feb 85 00:53:25-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: compiler status
To: jk@SU-AI.ARPA, rpg@SU-AI.ARPA
I have been hacking the compiler constantly this weekend but didn't get
it to where I wanted it. I won't have a chance to hack on it again
until next Friday evening.
If you need it this week I can generate a tape tomorrow night so
you will receieve it Wednesday am. Let me know what you want.
Here is the current status:
tail recursion has been completely redone so it works with intervening
lets and anywhere else it ought to. also it now works when there
are &optional and &rest args around. it will currently break if
there are &key args--estimate 2 to 4 hours to fix.
let optimizations have been significantly improved.
keywords work in all cases in embedded lambdas.
keywords in a defun work only when neither &optional nor &rest are
present. those cases currently break through a combination
of compiler bugs and runtime fastcall routine bugs
--estimate 2 to 3 hours to fix, but I'm always optimisitic.
I have not yet put any supplied-p code in--I suspect it will
take a lot of hacking to get everything optimal. Is this
a high priority?
Rod
-------
Jan tells me you will be joining us in a few weeks!
I have tentatively scheduled you to start hacking on the APOLLO
project with Dick; I am imagining Dick doing the coldload and gc
and you handling IO and interrupts. I would like it if you could
take this project on as a project leader; that is, be responsible
for co-ordinating, overseeing and scheduling the effort. And keep
in touch with the APOLLO technical folks.
Another thing: Would it be possible for you to get hold of a public
domain EMACS for the APOLLO from Yale? I am told such a thing exists.
JK
∂08-Feb-85 0841 @MIT-MC:BROOKS@MIT-OZ End march trip
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 8 Feb 85 08:39:00 PST
Date: Fri 8 Feb 85 09:10:51-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: End march trip
To: ftl@SU-AI.ARPA
Jussi,
Further to my note last wekeend. I could arrive in Palo Alto about 3pm Thursday
March 28 and leave the evening of Tuesday April 2nd.
Rod
-------
∂08-Feb-85 2231 ROD for EB
Well its one of those cases of ``how did this code ever work?''.
My test cases were not too adequate in retrospect.
Here are the minimal changes to make it correct semantically.
In my next tape I'll have a much cleaned up version which
achieves the same result but less screwily. Also I'll handle
the setq's better. If you look at the code generated for your
example now you'll see it is quite horrid. The setq stuff will
clean it up a lot, but it also has made me realize
that now that the alpha phase uniquifies names I can be
musch more aggressive in the if optimizer doing things like
(if (let (...) <body>) <then> <else>)
==>
(let (...) (if <body> <then> <else>))
This was not possible before because of shadowing possibilities.
Anyway I'll include such an aggressive if optimizer (in
your example case it would get rid of most of the horridness
by itself just leaving an instruction or two for the let-setq
handler (or primop reshaper, which is where that case will get taken
care of)).
Here are the changes:
In analyze-optimize-let:
1. (if (and (memq vnode readers)
(null (rest (%variable-refs vnode))))
(mul...
==> (if (and (memq vnode readers)
(null (rest (%variable-refs vnode)))
(or (eq bind-type 'procall)
(eq bind-type 'primop)))
(mul...
2. (cond ((and (cond ((eq place-type 'primop)
(if place-fastp
...))
(t 't)
==>(cond ((and (cond ((eq place-type 'primop)
(and (eq bind-type 'primop)
(if place-fastp
...)))
(t 't)
In analyze-extract-reference the (eq type 'primop) clause of the big
cond becomes:
((eq type 'primop)
(multiple-value-bind (place passers)
(analyze-extract-ref-seq refcell
(%primop-args internal)
anode)
(if (and place
(memq (first refcell) (first (%anode-source anode))))
(values anode passers)
(values place passers))))
Rod
EJG - shipping and installing this bugfix - Sat 850209
∂10-Feb-85 0825 ROD losing let value bug
To: RPG
CC: FTL
This was a side effect of fixing tail recursion... the bug was
also in multiple-value-bind and block. Here's the fix:
Right at the end of analyze.lisp at the end of the definition of
label-destinations it says:
(push ret collect)))))
(setf (%anode-returns node) collect)
collect))
<eof>
should have a line of code added to make it:
(push ret collect)))))
(setf (%anode-wantloc node) wantloc)
(setf (%anode-returns node) collect)
collect))
<eof>
EB: Added this fix to analyze.lisp 850210 1315
∂10-Feb-85 2151 ROD compiler status
To: RPG, FTL
The compiler now:
Handles all cases of &rest, &optional, &key and &aux in any combination in
defuns and embedded lambdas.
Handles supplied-p parameters in &key in defuns and in &optional in embeedded
lambdas, but not the other way around (I did the easy cases first...).
Generates better code for (if (let ...)...) than it did before.
Has the bug fixes that I've sent the last few days.
Immediate plans are:
Do the other two cases of supplied-p parameters (maybe tomorrow night).
Make tail recursion work on cases besides fixed args, &optional and &rest.
Get on to closures.
When all but the last item is done the only things missing from the handling
of lambda lists will be the cases where the variables are declared special.
(Note that specials already work in embedded lambdas--we're only talking
about special parameters to functions here.)
The optimal code for all the possible combinations will require a lot of
compiler code to generate (my stomach turns at the thought of a special
supplied-p parameter for an optional, which must be specially bound
before the next default value gets computed!). I think it should be low
priority as no one in Lucid ought to write code which uses such a brain
damaged feature--I also suspect it would be a year or two before you got a
bug report if we left out the hairier cases, but on the other hand I bet
we could make a test suite to break any other CL implementation...
Get on to closures.
Another thing not mentioned in Jussi's list, which probably should be done
reasonably soon (maybe after all multiple value stuff is fixed) is handling
special declarations.
I can send a tape any time of you want the current version or you can
wait a week or so to get a better one.
∂11-Feb-85 1816 ROD (if (progn... bug
To: RPG, FTL
I was trying to be too clever about avoiding some re-alphatization.
In alphatize-if in alpha.lisp there is a do in the first case
of the big cond. The return value is
`(progn ,@(nreverse others)
(if ,(first forms) ,b ,c)
wrap this in a call to alphatize like:
(alphatize
`(progn ,@(nreverse others)
(if ,(first forms) ,b ,c)
lexical
't)
(This bug is not new--I guess it had never come up before.)
EB - done.
∂10-Feb-85 1302 JK New reader
∂08-Feb-85 2250 SCHERLIS@CMU-CS-C.ARPA New reader
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Feb 85 22:50:34 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Sat 9 Feb 85 01:52:12-EST
Date: Sat 9 Feb 85 01:52:10-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: New reader
To: jk@SU-AI.ARPA
Jussi --
I just delivered a new reader to [1,FTL]. The files are:
(1) Code: RDECL, R0, R1, R2, R3, R4, R5, R6 -- all .LSP
(2) Debugging: RINIT, RTEST -- also .LSP
(3) Specification and Documentation: RSPEC.TXT
The reader is now complete except for two modules, BACKQ and SHARPM
(though the dispatching exists already), and two very minor (one page)
functions, PARSE-INTEGER and MAKE-FLOAT. Most of the code has received
very preliminary testing, but of course I still owe you a formal test
set. Nothing has been compiled, and in an interpreted system things run
slowly because of the giant TAGBODY.
You can actually load and run the reader on the Perq. But I'm
temporarily using the names *read, *read-line, *read-table*,
*read-delimited-list, and *read-preserving-whitespace in order to avoid
getting clobbered by errors. Thus, after initializing (calling
INIT-READER and then assigning *standard-readtable* to *read-table*) you
can say
(setq sample "(a '(bb::c 3.8e-5 158.) . \"b\") 2\\37. |ab|c ")
(setq s1 (make-string-input-stream sample))
(*read s1)
(*read s1)
(*read s1)
(*read s1) ; will give an error.
$G
(*read s1 nil 'foo)
and so on.
The files are much larger than I expected they would be. There are
about 60 to 65 pages of code and 45 pages of specification and
documentation. (I haven't counted lines, but I know the FSM alone is
about 750 lines.)
Has anybody started to read the first batch of code?
This delivery is a bit late, I know: The CLM specifications for the READ
flags are a bit ambiguous and Spice does it all wrong. (I had thought I
could borrow heavily from them -- not so.) You will want to look at
RSPEC to see what choices I have made.
I will get the rest to you shortly. The first priority will be
PARSE-INTEGER and MAKE-FLOAT, both of which are quite easy. Test data
will follow that; then BACKQ, and finally most of SHARPM (except #. and
#,).
Please let me know if this is a reasonable order to do things.
Also, please send comments concerning the code and documentation. Will
my buddy (is it RPG?) do a specification presentation?
I got your testing functions and will use them to make up the test set.
I'm afraid that it will be enormous. (For example, there are about 40
distinct error messages to be elicited. Most non-EOF errors are
continuable.)
My travel plans are still uncertain. I will come out there for 10 days,
but I am not yet sure when. The most likely time is now late Feb/early
March.
Could you send me a brief status report of the hacking activity there?
Regards,
Bill
-------
∂12-Feb-85 1915 JK Reader, continued.
∂12-Feb-85 1624 SCHERLIS@CMU-CS-C.ARPA Reader, continued.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Feb 85 16:24:06 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Tue 12 Feb 85 19:25:43-EST
Date: Tue 12 Feb 85 19:25:39-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: Reader, continued.
To: jk@SU-AI.ARPA
Jussi --
I just today got your handwritten comments of 2 Feb concerning
the reader. Here are some responses:
(1) [Add typechecking code.]
Will be done in the next version.
(2) [Can't find dispatch stuff.]
Fixed in your latest version (of 9 Feb).
(3) [Error msgs in specification.]
Fixed in your latest version (of 9 Feb).
**(4) [User friendly message.]
The context should be the last few lines (if reading from a
file) and the prefix of the current line. Could this be managed as part
of the read-char buffering mechanism, or should it be an explicit part
of the reader? (If it should be part of the reader, I'll include it in
the next version.)
--------------------
It should be an explicit part of the reader ---- maybe keep the last expression
read from the same stream in a global.
(5) [> to >&]
Will be done in the next version.
**(6) [List "non-trivial" outside functions.]
Will be done in the next version. By the way, do we have any
kind of "Masterscope" facility that will list functions used and free
variables referenced? It should be easy enough to write....
--------------------
Martin Brooks wrote something like this --- it does not run yet.
**(7) [Reader-read-char]
Will be done. QUERY: What does BUFFERED-READ-STRING-CHAR return
in the event of EOF. Also, the reader must accept all chars, not just
string chars. What are the plans for fonts and bits? (See my docn on
this point: We will eventually have to write primary attribute table
code that handles the full range of characters.)
-------------------
We have currently no plans for fonts and bits --- this will appear much
later; don't worry about it.
Buffered-read-string-char behaves like read-char.
**(8) [Inline.]
Please send me DEFSUBST and documentation so I can do testing
here. I don't have functional specification for DEFSUBST!!
--------------
Our defsubst expands into wierd compiler-macro hacking, so you can't use it.
In the future, Defsubst expands into defun plus inline proclamation, thats all.
So write a macro defsubst that expands into defun for time being.
(9) [CLM refs.]
Point taken.
(10) [eql to =&]
Will check for these.
(11) [read-suppressed-token]
Fixed in your latest version (of 9 Feb).
(12) [return-from comment]
Fixed in your latest version (of 9 Feb), but I'll clarify further.
(13) [potnum]
There is a problem here: In the specification, I define a POTNUM
as a potential nunmber that is NOT also a number. We need a term for
this kind of strange object -- saying "potential number" in error
messages is misleading and wrong because all numbers are also potential
numbers. Choices: [a] Write more elaborate error messages. [b] Define
POTNUM in our user documentation.
----------------
We'll define potnum in user documentation.
(14) [Errors]
See my remarks at point (4) above.
Jussi, I would appreciate any general stylistic comments as well,
hlwever negative. We are all new to Common Lisp programming, and it
would be helpful if we could criticize each other's coding style in
addition to functionality.
-----------------
Your style is excellent, no problems.
The main problem that I see is getting the job done fast and getting you here
as soon as possible to install and gettin the test files.
We need you to do other stuff as soon as possible --- we are very short on
man power.
Could you send me a brief status report of the hacking activity there?
----------------
We are currently into the integration and test phase for stage 2 ---
doing lots of compiling; I have placed the stage 2 report in your box.
Would be glad to tell you more on the phone, so call if you want to know more.
Please respond soon, but most urgently regarding points 4, 6, 7, and 8.
Thanks,
Bill
-------
∂12-Feb-85 2128 @MIT-MC:BROOKS@MIT-OZ Re: compiler and macros
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Feb 85 21:28:01 PST
Date: Wed 13 Feb 85 00:29:55-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: compiler and macros
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Tue 12 Feb 85 20:05:00-EST
The bug concerning blocks and return-froms was harder to track down
than I expected. The problem is in reanalyze which should be redefined
as:
(defun reanalyze (form env stackheight)
(let ((oldstate (save-lexical-env env)))
(let ((newform (alphatize form env 't)))
(restore-lexical-env
env
oldstate)
(let ((newnode (analform newform
stackheight
env)))
(setf (%anode-redone newnode) 't)
newnode))))
----------
I'm working on the macros in different files problem (probably
tomorrow night)--whoever it was who sent me the message tonight
about it.
-------
EJG - transferred 850213 15:00.
∂13-Feb-85 2030 @MIT-MC:BROOKS@MIT-OZ defmacro in the same file bug.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Feb 85 20:30:22 PST
Date: Wed 13 Feb 85 23:31:50-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: defmacro in the same file bug.
To: ftl@SU-AI.ARPA
cc: rpg@SU-AI.ARPA, ejg@SU-AI.ARPA
Here are the changes necessary to get it so that you can have a
defmacro in a file and use it in the next function without it
complaining, and with it getting the right macro expansion (actually
it used to often compile the right thing even when it complained
but that was mostly fortuitous--it didn't always get things
right).
Note that compdefs.lisp is changed below. This means *everything* will
get recompiled when you make the new compiler. Many files actually
should be recompiled so it will be hard to circumvent it without
losing.
(Note to EB: defmacro currently uses 1- and =. Would be better for
lcl if it used 1-& and =&. I'll fix the eval-when bogosity over the
weekend and ship out a tape of everything on Monday.)
/mods/lap/asm.lisp
Change the definition of assemble form by inserting `type' between the
second and third arguments in the call to check-definition-consistency.
Thus it becomes
(check-definition-consistency
name
(make-%interval :lo 0 :hi ())
type
't)
/mods/compiler/alpha/alpha.lisp
Change the definition of alpha-macroexpand. There is an or clause
with three subforms. The second of these is:
(get name 'function-descriptor)
Change this to be
(let ((fdesc (get name 'function-descriptor)))
(and (not (null fdesc))
(not (eq 'macro (%fdesc-proctype fdesc)))))
Change the definition of check-definition-consistency by adding a
third required argument `proctype'. So the defun line looks like
(defun check-definition-consistency (func argrange proctype
&optional (assemmdef 'nil))
and add a :proctype arg in the call to make-%fdesc to make it:
(make-%fdesc
:function func
:type 'user
:proctype proctype
:args (make-%interval :lo loargs :hi hiargs))
(The version here has some other stuff added for extra error checking
and warnings about redefining macros as functions and vice-versa, but
its earier to wait for the tape to get that.)
/mods/compiler/analyze/analyze.lisp
In the function analyze change the call to check-definition-consistency
to include a third argument. Now it looks like:
(check-definition-consistency
name
(%lambda-expected lnode)
ftype)
/mods/compiler/compdefs.lisp
Change the definition of %fdesc to include a new field `proctype'.
I added it right after the `type' field and before the `args' field.
-------
EJG - transferred 850214 12:00.
∂15-Feb-85 0814 JK Re: jobs
∂14-Feb-85 2135 sandy@Whitney Re: jobs
Received: from SU-WHITNEY.ARPA by SU-AI.ARPA with TCP; 14 Feb 85 21:35:42 PST
From: William "Sandy" Wells <sandy@Whitney>
Date: 14 Feb 1985 2137-PST (Thursday)
To: Jussi Ketonen <JK@SU-AI.ARPA>
Cc: sandy@Whitney
Subject: Re: jobs
In-Reply-To: Jussi Ketonen <JK@SU-AI.ARPA> / 11 Feb 85 2025 PST.
I really appreciate your contacting me about working for Lucid.
It's an attractive invitation. I'm most interested in
working in vision and robotics. I've managed to find a
contingency situation in robotics and AI at SRI. Good luck with Lucid, I
expect you will do well as I think there will be a good market, and
you folks are the obvious people to do a first rate job of it.
-sw
Rod ---
Sun would like to have an alpha version of our system for in-house
testing by May 1. This means the end of the next 6-week cycle.
It seems that we can deliver a very good subset to them at that time
provided that we can extensively test and productize our code before
that. The most crucial items for us are the gc (which rpg is doing),
eval (which eb is doing right now), and the compiler (you).
Before we can think in terms of delivery, we should have the compiler
in a fully functional state (optimization issues taking the back seat)
and be capable of maintaining it here at Lucid with some minor help from you.
The most preferable scenario in my mind would be for you to add all the
items necessary to make the compiler a full common lisp compiler during
the next four weeks and then us taking over the compiler in the sense of
making it more user friendly, testing it, and being able to maintain it
here at Lucid. At the same time your help would be needed in learning
its innards and hacking it for performance.
To make your compiler fully functional, I can at least see the following
tasks:
(0) Remains of lambda keywords
(again, performance is not important for supplied-p hacking etc.)
(1) Full closures (flet, labels, macrolet, too.)
(2) Special declarations
(3) Multiple value stuff (catches, throws, etc.)
I don't think performance is a crucial issue on any of these. The main
point is political; we need to have a correct and complete compiler.
Also, EB tells me that closures would be real nice for his eval stuff, too.
JK
∂17-Feb-85 0425 @MIT-MC:BROOKS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Feb 85 04:25:30 PST
Date: Sun 17 Feb 85 01:42:35-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Sat 16 Feb 85 13:08:00-EST
Jussi,
I will endeavor to send a tape containing the rest of lambda list stuff,
many bug fixes and some multiple value stuff EB needs right away on
Tuesday (Monday is a holiday so I'm not sure Fed Exp will be open).
That will leave special declarations (which I think will be fairly
easy), the rest of multiple values with catches etc. (which are easy
except for an efficient multiple-value-call, but not too bad for
an inefficient one) and full closures (which will tax me greatly).
It may be pushing things to get flet, labels, and macrolet all
in in the next four weeks.
After I send the tape on Tuesday and that stuff has been integrated
I would appreciate getting the latest complete set of module files--
I'm still running a Jan 14th version of Lucille which is pretty
minimal.
Rod
-------
Rod ----
sounds good. We will send you the new stuff as soon as possible.
Your trip in March would be of crucial importance to us;
let me know if there is anything you need from us in that regard.
JK
Bill ---
Sun would like to have an alpha version of our system for in-house
testing by May 1. This means the end of the next 6-week cycle.
When are you going to be here? We need you to install the reader
and the rest of the stuff as soon as possible.
JK
∂17-Feb-85 2113 ROD adjust-stack bug
To: RPG, EJG
Here's the fix:
The last function in analyze.lisp has a big cond. The last clause goes:
(t (setf (%anode-wantloc ret) wantloc)
(setf (%anode-wantrep ret) wantrep)
(push ret colllect))...
Remove the two setf's and place them at the head of the cond, as the
first two expression in the enclosing let, so it looks like:
(let ((type (%anode-type ret)))
(setf (%anode-wantloc ret) wantloc)
(setf (%anode-wantrep ret) wantrep)
(cond ((eq type 'block)
...
EB installed 850217.
∂18-Feb-85 0823 JK tape
∂18-Feb-85 0652 @MIT-MC:BROOKS@MIT-OZ tape
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Feb 85 06:52:15 PST
Date: Mon 18 Feb 85 09:54:00-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: tape
To: eb@SU-AI.ARPA
cc: jk@SU-AI.ARPA
I'll be sending it off Tuesday to arrive Wednesday am.
I have multiple-value-list, values-list and multiple-value-setq (trivial
macro) all working as optimally as I can see how to do.
(Question: what's the quickest way in Lucille to make a top level
copy of a list? Answer: (multiple-value-list (values <list>)) !)
I realized how to make supplied-p's for optionals work without having
to shift all the arguments above. The cost is that non-trivial
defaults take an extra instruction, as now the empty supplied-p's,
keyword blocks etc. get set up before the defaults are computed,
in the case there are optional supplied-p's. I hope to have that
working by the time I make the tape.
As for specials in lambda lists. They already work in embedded lamdba's
and I made them work in multiple-value-bind yesterday. As a quick hack
for now, I'm going to scan for them in the lambda list of a defun,
and if there are any there make the defun take an &rest arg as soon
as they start, then use a let to destructure into the right things.
The stack debugger will have to be cleverer to hide this from the user.
-------
∂18-Feb-85 2133 EB
∂18-Feb-85 2018 ROD eval-when
I made it work just like pages 69 and 70 of the aluminum edition,
but it seems to me the result os not what you would expect. In
particualr according to my reading of the definition, a top
level defmacro does not get evaluated in the compiler's environment!
So I added a third mode, namely toplevel, and it does everything
pretty much as you would expect. The only thing you might find weird is that
(eval-when (load) (defmacro foo ...)) causes foo to
get compiled, but not evaluated in the compiler's environment. I
guess I'm use to foo not being compiled in those circumstances,
but actually this way seems better. To not have it compile
would require even greater divergence from the CL spec.
∂18-Feb-85 2031 SCHERLIS@CMU-CS-C.ARPA travel
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 Feb 85 20:31:08 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Mon 18 Feb 85 23:32:44-EST
Date: Mon 18 Feb 85 23:32:42-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: travel
To: jk@SU-AI.ARPA
Jussi --
At the moment, it looks like I will travel to California in
the very beginning of March -- arriving sometime March 2 and staying
for about 10 days. Unfortunately, I cannot come any earlier as I
have important visitors here on 1 March.
I'll call sometime in the next few days for a status report.
I also expect to ship another batch of code (including revisions to
the last batch) to you in the next week. My major priority at the
moment is testing; I'll try to have a test set worked up before I
arrive there.
Backquote is relatively easy, but sharpm is a bit tedious and
will probably wait until I am out there.
I hope all is well.
Bill
-------
Bill --
Sharpm shouldn't wait till you get here; if you are going to
be here only for 10 days, I suspect that you will spend all your time
integrating the stuff into the system. The reader with all the extras
is becoming a time critical item; it can't be any later than it already
is.
JK
∂19-Feb-85 0853 JK
∂18-Feb-85 2237 @MIT-MC:BROOKS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Feb 85 22:37:25 PST
Date: Tue 19 Feb 85 01:43:38-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
To: EB@SU-AI.ARPA
cc: rpg@SU-AI.ARPA, jk@SU-AI.ARPA
In-Reply-To: Message from "Eric A. Benson <EB@SU-AI.ARPA>" of Mon 18 Feb 85 21:48:00-EST
To EB: The (eval-when (load) ...) does suppress the macro defintion
getting into the compile time environment in ther version I'm sending.
I don't think eval-when will do anything you don't like.
To all: I'm holding off another day sending the tape in the interest
of tracking down another stackheight bug EB jsut sent me, and to
finally get supplied-p's for optionals finished. I'll send it
out Wednesday.
-------
∂20-Feb-85 0739 JK tape
∂19-Feb-85 2206 @MIT-MC:BROOKS@MIT-OZ tape
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Feb 85 22:06:28 PST
Date: Wed 20 Feb 85 00:34:30-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: tape
To: jk@SU-AI.ARPA, rpg@SU-AI.ARPA, eb@SU-AI.ARPA
I am sending out a tape Wednesday to you. It contains all the bug fixes
I have sent the last couple of weeks, plus more bug fixes (eg the if
of a literal one), plus a whole lot of enhancements, mostly to do
with lambda lists and specials. I still don't have supplied-p's
for optionals in defuns working, and have not included that code--
I assume this is not time critical. As soon as I have got that
working I will make specials work in defun lambda lists (with
a quick hack) then move on to cleaning up multile value interactions
with unwind-portect, catch etc. and making go work when it
passes a catch or unwind-protect. Then closures.
See the file log3 on the tape for a detailed description of all
changes.
-------
∂20-Feb-85 0757 SCHERLIS@CMU-CS-C.ARPA Re: travel
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Feb 85 07:57:34 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Wed 20 Feb 85 10:59:00-EST
Date: Wed 20 Feb 85 10:58:48-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: Re: travel
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Wed 20 Feb 85 07:48:00-EST
Jussi --
Given the time constraints, it would be useful for me to
have some indication from you of the relative priorities of the
various reader-related tasks remaining. This especially given that
I have exactly ten days HERE before I leave from California.
Bill
-------
Do it all. You have 10 days.
JK
∂21-Feb-85 0733 JK ["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>: Kyoto Common Lisp]
∂20-Feb-85 2041 SCHERLIS@CMU-CS-C.ARPA ["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>: Kyoto Common Lisp]
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Feb 85 20:41:32 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Wed 20 Feb 85 23:43:16-EST
Date: Wed 20 Feb 85 23:43:15-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: ["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>: Kyoto Common Lisp]
To: jk@SU-AI.ARPA
Jussi --
You guys will be interested in this, perhaps. (Don't worry, I
won't be involved with the port -- the letter was primarily to SEF's
group.)
Bill
---------------
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 20 Feb 85 23:39:59-EST
Date: Wed, 20 Feb 1985 23:39 EST
Message-ID: <FAHLMAN.12089345811.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: slisp@CMU-CS-C.ARPA, rfr@CMU-CS-SPICE.ARPA, dzg@CMU-CS-SPICE.ARPA,
rvb@CMU-CS-SPICE.ARPA, scherlis@CMU-CS-C.ARPA, spector@CMU-CS-C.ARPA,
accetta@CMU-CS-A.ARPA
Cc: wactlar@CMU-CS-A.ARPA, mcdermott@CMU-CS-C.ARPA
Subject: Kyoto Common Lisp
I just got a letter from Taiichi Yuasa and Masami Hagiya at Kyoto
University. These are the guys who, all by themselves out in the woods,
managed to get a full (so they say) Common Lisp running on the Data
General Eclipse about a year ago. Anyway, they will be be visiting CMU
on April 1 and 2. They say that they have ported their Common Lisp to
Vax/Unix (4.2bsd) and to the Sun, and they would like to bring this code
and install it for us when they come. Their implementations probably
will be slower than the ones from DEC and Lucid respectively, but to
have any Common Lisp at all on those machines would be very nice for us
until DEC and Lucid deliver. I will ask them to bring along sources, if
possible, so that we can take a crack at getting this stuff running
under our 4.1 systems as well, and integrated with the ITC code for the
Suns.
I will probably be asking some of you to spend some time talking with
these guys and to help with installing these systems on various machines
around here. Just thought I'd give you some early warning. I assume
that the place to do the Sun work is over at the ITC (with Dave McDonald
either helping or finding some Sun wizard to help) and that Bob Baron
can help with installing the Vax/Unix 4.2 version, with perhaps some
help from Rashid and Accetta.
-- Scott
-------
∂22-Feb-85 1819 JK trip to Lucid
∂22-Feb-85 1334 @MIT-MC:BROOKS@MIT-OZ trip to Lucid
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Feb 85 13:33:54 PST
Date: Fri 22 Feb 85 16:35:51-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: trip to Lucid
To: jk@SU-AI.ARPA, rpg@SU-AI.ARPA
I have just bought tickets (at bargain basement rates by doing it
today rather than Monday) for a trip to Lucid late March. I arrive
around 2pm Thurs 28 march and leave Tuesday 2nd April at 1pm. Thats 5
days in town. I have no other time commitments in Palo Alto. I can't
squeeze more time in between teaching and research contract monitor
malarky. I've been working on the assumption that I will find money
to pay my fare, and Lucid will pay Nui's (I never got a reply to that
suggestion). The tab for Lucid is $258.
-------
∂26-Feb-85 1027 FTL
closures
How are closures coming along? RPG said that he would contact you about
some ideas of his, mainly reading the S-1 code.
We have 3 weeks left on this cycle of development, projected end would
be March 18. At that point EB and to some extent me would like to
take the responsibility for the code so that we are ready for your
visit March 28.
JK
∂26-Feb-85 2015 @MIT-MC:BROOKS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Feb 85 20:15:45 PST
Date: Tue 26 Feb 85 23:18:21-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Tue 26 Feb 85 10:28:00-EST
No coding has started for closures. I will make sure RPG talks to me
soon. I have all the supplied-p's/keywords/optionals etc. completed.
I expect to get the extra cases of specials in argument lists done
tomorrow night, and fix go, unwind-protect etc over the weekend. That
leaves two weeks for closures according to your schedule. I'll try.
Keep hounding me.
-------
∂02-Mar-85 1754 JK Reader
∂01-Mar-85 2223 SCHERLIS@CMU-CS-C.ARPA Reader
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Mar 85 22:23:35 PST
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Sat 2 Mar 85 01:25:32-EST
Date: Sat 2 Mar 85 01:25:29-EST
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: Reader
To: jk@SU-AI.ARPA
Jussi --
I just shipped a new set of reader files to SAIL. The files
are R*.*[1,ftl]. The spec is in RS*.TXT. The code is in R*.LSP. Two
of the code files (RTEST and RINIT) are used only for debugging.
MK-FLOAT is done. Most of Sharpm is done. Backq will be
done when I arrive. I still need to build a formal test set and
write parse-integer.
I'll be at Lucid Monday morning. See you then.
Bill
-------
∂03-Mar-85 0936 JK compiler
∂02-Mar-85 2032 @MIT-MC:BROOKS@MIT-OZ compiler
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Mar 85 20:31:55 PST
Date: Sat 2 Mar 85 23:28:51-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: compiler
To: rpg@SU-AI.ARPA, jk@SU-AI.ARPA, eb@SU-AI.ARPA
The current version of the compiler which you have never does tail merging.
To fix it you can mopver the three lines starting from
(label-destinations... in finishup-lambda in analyze.lisp to follow
the first line of the body of that function (the one that setf's
the %lambda-body).
-------
∂04-Mar-85 1107 JK status, hint and query.
∂03-Mar-85 1356 BROOKS%MIT-OZ%MIT-MC.ARPA.#Internet@MIT-XX.ARPA status, hint and query.
Received: from MIT-XX.ARPA by SU-AI.ARPA with TCP; 3 Mar 85 13:56:05 PST
Received: from MIT-OZ by MIT-XX via Chaosnet; 3-Mar-85 16:57:23-EST
Date: Sun 3 Mar 85 16:57:14-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: status, hint and query.
To: rpg%sail@MIT-XX, jk%sail@MIT-XX
cc: rpg@SU-AI.ARPA, jk@SU-AI.ARPA, eb@SU-AI.ARPA
MC seems to be down so any reply should go to "brooks%oz"@mit-xx.
Status.
o All possible cases of lambda's with supplied-p's and/or specials and/or
anything else legal now work.
o All possible cases of self tail recursion, no matter how hairy the lambda
list now work.
o The let optimizer is much better with internal setq's so tail recurrence
and psetq should be much more efficient than before.
o I'm now working on making go, return-from etc. break up catch frames
and fixing throw to handle multiple values. I may add a new way to
handle special binds for efficiency and for the sake of progv, a special
form which is not yet done.
Hint.
If someone is writing the billion functions that use keywords the following
may be relevent someplace (I thought it would be in equal but that
doesn't take keywords). Suppose you have an anonymous function used as
a predicate (probably handed in as a :test argument) and you have it
in a tail recursive place. E.g., (funcall test x y) in a tail recursive
place. The compiler can't tell how many values will be returned by funcall
and must assume the worst. It may be the case that the function writer
knows that only one will be used by the caller. This can be declared
by writing (values (funcall test x y)) instead. It generates precisely
as many instructions as it would have had it thought funcall always
returned exactly one value.
Query.
I've been thinking about the suggested way to implement closures following
the S-1 approach. However I don't think we can treat downward and upward
funargs identically, because block names and go tags are defined to
have lexical scope and dynamic extent. See examples on page 40 and
41 of the aluminum edition. So I think for downward funargs I need to
turn return-from/block pairs and go/tagbody pairs into throw/catch
combos. This will result in errors at the right time (e.g. page 41)
although we'll have to be clever to make the error messages meaningful
to the poor user. Does the above seem right?
-------
How's closures? RPG tells me he told you all that you ever need to
know about the stuff. McDonald is doing the new lap; this will include
the necessary support stuff. By the way, GC works and EJG
just got disksave to work.
JK
∂06-Mar-85 1915 @MIT-MC:BROOKS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Mar 85 19:15:19 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 03/06/85 22:14:03
Date: Wed 6 Mar 85 22:13:50-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Wed 6 Mar 85 08:55:00-EST
I think I know what I have to do (modulo the details) to get full CL
closure capabilities. I am currently implementing progv (needed by the
interpreter), and concurrently redoing go, return-from, throw, catch
and unwind-protect to bring them up to CL spec. The original verisions
(a) handled only single values, and (b) insulated all lexical objects
(except variables) created outside them, making them invisible from
within. The new way of doing this is a necessary pre-requiste for
getting closures to work right, and all of these special forms
interact with each other and with closures. I hope to get all that done
by Saturday. Then I can work on the analysis phase of closures,
most of which will just be using the extra stuff I'm putting
in lexical enviroments (at analysis time) for the above. I plan on
sending you a tape of everything on March 18th. Then I will have to
work with McDonald when I'm out there to integrate code generation
with his new Lap. I have reduced my sleep phase considerably to
accomodate these goals. I will not be able to continue at the current
level of effort into April, and will want to scale back to more like
16 hours a week.
Disksave! Just like a real lisp, eh?
-------
Glad to hear you're working hard .....
Seriously speaking, the closure stuff is extremely important for the alpha
test since we suspect that Pratt will be the main SUN evaluator of our Lisp.
After it is done, I see no reason for you to have to slave away at the present
rate; I foresee EB and me (and possibly also RPG) taking over compiler stuff
with minor help from you in performance issues etc. You could start working
on a fancy inspector which is not as much of a time pressure item.
We are currently planning for the Big Hiccup which means bringing in:
(1) JONL's package code. This affects coldload, too.
(2) New lap, and new fasl format.
(3) GC and areas.
(4) McDonald's IO and Scherlis's reader.
(5) The Benson lexical evaluator
The hiccup is mainly caused by the new fasl format and package stuff.
The rest of the stuff can be integrated without too much pain.
JK
∂10-Mar-85 0755 JK
∂09-Mar-85 1442 ROD disk
To: JK, RPG
ROB blames an alpha particle and thinks all the noise I heard coming
from the disk was the heads retracting to do a recalibration when
the disk looked weird to it. It turned out there was pretty minor
damage to the file system--the only file I lost was a lock file
for the uucp spooler! But of course I didn't know that without
help from a unix wizard.
I have tapes of everything that Lucid doesn't now. I'll start backing
up to tape either every day, or twice a week or something. Maybe I
should send a weekly tape to Lucid too. And getting real paranoid,
maybe a cheap printer ($300 or $400) would be a good idea, as I
could list off all files I changed at the end of every session.
(I've just this week reorganized the files to be many smaller files
than before to save the amount of recompiling unchanged stuff I was
doing.)
I'll send a tape monday with the latest stuff. You might decide
to wait till the next round rather than integrate this one.
∂11-Mar-85 0841 JK 68020
∂10-Mar-85 2244 @MIT-MC:BROOKS@MIT-OZ 68020
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Mar 85 22:44:26 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 11 MAR 85 01:43:10 EST
Date: Mon 11 Mar 85 01:43:05-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: 68020
To: rpg@SU-AI.ARPA, jk@SU-AI.ARPA
In talking with Web Augustine on Thursday I discovered that the SUN-III
architecture is locked into 28bits of addressing--I had assumed
they would use the full 32. Anyway that gives 26 bits of pointer
addressing which is 1 more than TI's explorer (which itself
made use of one more available one than did MIT CADR's), and 3 less
than 3600's.
Gee--maybe we should have used those top four bits and then we
wouldn't have had to worry about this lowtag malarky at all...
-------
∂11-Mar-85 0843 JK tape
∂11-Mar-85 0828 @MIT-MC:BROOKS@MIT-OZ tape
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 11 Mar 85 08:27:49 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 11 MAR 85 11:25:58 EST
Date: Mon 11 Mar 85 11:25:52-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: tape
To: rpg@SU-AI.ARPA, jk@SU-AI.ARPA, eb@SU-AI.ARPA
A tape is on its way. This is mostly for insurance but you can install
it if you want (let me know what you decide so I can make the next
tape contain only the necessary stuff.) Features include:
o throw is almost certainly broken (I'm half way through the upgrade).
o progv works completely when the number of variables can be determined
at compile time--missing two runtimes for the other case. this
includes a bunch of new multiple value handling stuff which seems to
work and which I'll now install in catch and unwind-protect to bring
them up to spec.
o redone multiple value returning--basically cleaned up part of
coerce-loc-and-rep and added new cases. (this also fixes RPG's
bug when a function tries to return 0 values.)
o **full CL lambda lists including specials being allowed anywhere.**
o much better code produced for most tail recursions due to better analysis
of setq interactions (I used to just punt on seeing the first one...).
o or is sometimes smarter.
This version gives the 11 instruction loop for shorterp. If tak was
doing anything stupid in shuffling things on and off the stack (I
don't remember whether it was) then that will be fixed by this version
too.
-------
∂13-Mar-85 0758 JK status
∂13-Mar-85 0722 @MIT-MC:BROOKS@MIT-OZ status
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Mar 85 07:22:21 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 13 MAR 85 10:21:21 EST
Date: Wed 13 Mar 85 10:21:10-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: status
To: jk@SU-AI.ARPA
You wanted me to be finished by Monday March 18th. Thats a good finishing day
for me until I get out to PA as I have lots of travel starting then.
Here's what I realistically expect to get done by next Monday:
THROW, CATCH, UNWIND-PROTECT, PROGV, GO, RETURN-FROM all up to full CL
spec with respect to their interactions and multiple values.
Closures: alphatization and analysis. No code generation.
This leaves the following to be done to make the compiler full CL:
Closure code generation.
LABELS, FLET, MACROLET (the latter is pretty trivial).
Making it listen to local special declarations--this is probably just an hour
or two's work.
I think that EB, RPG, JIM, JK and I, or some subset thereof working together while
I'm out there can get all of these finished.
-------
Sounds great ---- send us the code as soon as it is done so we can start looking
at it and figuring out who needs work on it.
I hope the last few weeks have not been too much of a strain on you -- thanks for
putting in the extra time.
JK
∂18-Mar-85 0716 JK tape
∂17-Mar-85 1956 @MIT-MC:BROOKS@MIT-OZ tape
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Mar 85 19:56:00 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 17 MAR 85 22:55:02 EST
Date: Sun 17 Mar 85 22:54:41-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: tape
To: jk@SU-AI.ARPA
cc: eb@SU-AI.ARPA, rpg@SU-AI.ARPA
I'm sending a tape off in the morning. Here's the status:
o Everything I reported last time still works. I believe the compiiler
is in a workable state and won't screw you if you use it.
o catch, throw, unwind-protect, progv, go and return-from all are up
to full CL spec (modulo detail below) with respect to scope and
handling multiple values. In particular the only time these guys
cons is when they are returning more than four values through an
unwind-protect. E.g. if throw is throwing 627 values through
a bunch of catches and progvs it does no consing and only moves
things on the stack once.
**NB** The format of catch frames has changed. Everything in lcl
needs to be recompiled, otherwise, for instance, the debugger
wont work.
o special binds now use progv instead of unwind-protect gaining much
efficiency.
o alphatization of closures is complete.
o environment analysis now includes keeping track of lexical contours.
this was needed to enable go and return-from to be fully general.
it also allows you to figure out where a variable is established
for closure analysis.
o the analysis phase is fully recursive and can walk over closures
with all the right environments set up.
o block and tagbody notice when they have a return-from or go down in
them hidden inside a closure. I have the transformations worked
out that need to be done in these cases, and have some runtime
support implemented for getting the right error message when they are done
illegally dynamically. This is about 1 to 2 hours work to finish.
(I may have time later in the week.)
o the support is there to do all the rest of the stuff RPG did on the
S-1 compiler, but putting it together is not yet done. I suspect
he and I can do it together in a days solid hacking.
----
My status: I'll be at CMU for 2 days starting in about 8 hours. Then
I'll be back here for 4.5 days catching up on a million things I've
put off the last month while hacking the compiler--I doubt I'll
have much time to hack on this during that time. Then I'll be in
St. Louis until I arrive in Palo Alto on THhursday 28th.
(If you're not going to use the new compiler before then at least
make sure you can read the tape by the end of this week.)
-------
∂23-Mar-85 1144 JK
∂22-Mar-85 2040 ROD SUN sevice contract
To: RPG, JK
Is my SUN under service contract? It is getting the same sort of disk
errors that happended two weeks ago tonight, but this time power
cycling doesn't help, and it doesn't get as far as letting me repair
the file system before it reboots again. (I'll try again
tomorrow but I'm not hopeful.)
Fortuneately I had just ifnished dictating some changes to EB so
there is nothing on the disk here that LIHQ doesn't have.
∂23-Mar-85 0802 ROD broke
To: RPG, JK
The SUN disk seesm well and truly broke--trasnfer errors, seek errors,
drive faults, etc. Can one of you ask Jan to figure out what should
be done re service contract. If she wants she could get someone to come
over here sometime during Monday through Wednesday (after calling
Nui at (617)863-8930 to make sure she'llbe home to let them in), or
we can just leave it till after I get back.
From tomorrow I can be reached at the St Louis Marriott Pavilion
(314)421-1776 if compiler bugs warrant it.
∂26-Mar-85 0843 JK For your info...
∂21-Mar-85 0902 ROB%CCRMA@SU-AI.ARPA For your info...
Date: 21 Mar 85 0851 PST
From: Robert Poor <ROB%CCRMA@SU-AI.ARPA>
Subject: For your info...
To: jk@SU-AI.ARPA, rpg@SU-AI.ARPA
[This excerpted from unix-wizards-digest. - Rob]
From: wegrzyn@encore.UUCP (Chuck Wegrzyn)
Subject: Public Domain EMACS available from GNU Project
Date: 20 Mar 85 16:03:20 GMT
To: unix-wizards@brl-tgr.arpa
The GNU project has released its first major subsystem,
the EMACS editor. This editor is a sophisticated screen
editor that is compatible and comparable with the EMACS
editors being sold by UniPress and CCA. It comes with
Mock Lisp ( did you know that UniPress trademarked MLISP??),
and all the little bells and features most of us expect
with EMACS.
The GNU version of EMACS, written by Richard Stallman, is
available for distribution. The distribution includes all
source code for EMACS and a source code level debugger.
Furthermore, under the GNU project banner, the EMACS system
can be distributed (in source code form) by one and all.
I was thinking of sending out the source code over the net,
but resisted : it is over 1Mbyte of code. If there is
enough demand, I will add a UUCP dial-in to our system, or
send out tapes, or ... ?
Is anyone interested in EMACS? If so, please tell me how
you think I should distribute it?
Chuck Wegrzyn
{allegra,decvax,ihnp4,princeton}!encore!wegrzyn
-----------------------------
∂02-Apr-85 0800 JK flavor ?s
∂01-Apr-85 1215 ssc-vax!steve@uw-beaver.arpa flavor ?s
Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 1 Apr 85 12:15:02 PST
Received: by uw-beaver.arpa (4.42/2.6)
id AA25407; Mon, 1 Apr 85 12:18:13 PST
Return-Path: <ssc-vax!steve@uw-beaver.arpa>
Received: by ssc-vax (4.12/4.7)
id AA14891; Mon, 1 Apr 85 08:39:56 pst
Date: Mon, 1 Apr 85 08:39:56 pst
From: ssc-vax!steve@uw-beaver.arpa (Steve White)
Message-Id: <8504011639.AA14891@ssc-vax>
To: uw-beaver!jk@su-ai.arpa
Subject: flavor ?s
This is a short description of the problem mentioned over the phone.
Flavors compose according to a depth-first expansion of the
components tree (modulo :included-flavors), cycles are broken by
ignoring any flavor already in the components list.
(defflavor a nil (c b)) ;C before B
(defflavor b nil (c)) ;B before C
sets up a situation where according to A, flavor C is searched
before B for method handlers, but B has been "defined" assuming that
its messages are searched before the handlers for C. This seems to
violate the encapsulation property that OOP regards so high.
The funny case is when B sets up a lock for some resource that
C uses, then its possible to create a deadlock situation by
sending instances of Bs & Cs the message in the wrong order.
(It's arguable that if the programmer specified the above combination
they would deserve the result) In any case it seems that this is
detectable and possibly a warning could be issued.
Another problem is using :before & :after callers,
(defmethod (a :before :tst) nil (format t "Before A~%"))
(defmethod (b :before :tst) nil (format t "Before B~%"))
(defmethod (c :before :tst) nil (format t "Before C~%"))
(defmethod (a :after :tst) nil (format t "Before A~%"))
(defmethod (b :after :tst) nil (format t "Before B~%"))
(defmethod (c :after :tst) nil (format t "Before C~%"))
(defmethod (a :tst) nil (format t "A Handled~%"))
then
(send (make-instance 'a) :tst) ==>
Before A
Before B
Before C
A Handled
After C
After B
After A
I'm not real sure it makes sence to run all the :before & :after
methods "lower" then the primary handler if the primary handler
also shadows "lower" primary methods.
ssc-vax!steve@uw-beaver
∂02-Apr-85 0801 JK this is a test
∂01-Apr-85 1140 bcsaic!steve@uw-june.arpa this is a test
Received: from UW-JUNE.ARPA by SU-AI.ARPA with TCP; 1 Apr 85 11:40:30 PST
Received: by uw-june.arpa (4.12/2.2)
id AA28196; Mon, 1 Apr 85 11:38:56 pst
From: bcsaic!steve@uw-june.arpa
Return-Path: <bcsaic!steve>
Received: by bcsaic.UUCP (4.12/1.0)
id AA10539; Mon, 1 Apr 85 11:39:34 pst
Date: Mon, 1 Apr 85 11:39:34 pst
Message-Id: <8504011939.AA10539@bcsaic.UUCP>
To: uw-june!jk@sail
Subject: this is a test
message to see if this route gets out, could you reply if this
got there via route "bcsaic -> uw-june -> sail", the first hop
is via UUCP the second is over ARPA, thanks
-steve
-----
got it.
∂03-Apr-85 2026 JK
∂03-Apr-85 1950 ROD randomness
To: RPG, JK, EB
I tried to boot the SUN at least 8 times over three days before I left for
St Louis. The SUN person is coming tomorrow at 10am. Just for fun I tried
booting it tonight--if corrected a coouple of errors in the file system
and booted just fine--not a single disk error.... So I'll call SUN in
the morning. Maybe its a flakey cable.
In any case please send me a tape of /mods, the big Franz Lisp,
EJG's 53 line emacs, and /pub/usr/rod. If you send it out Thursday
I can hack over the weekend. Make sure EB includes JONL's bug
tickling code too.
∂08-Apr-85 0822 JK tape
∂07-Apr-85 2219 @MIT-MC:BROOKS@MIT-OZ tape
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 Apr 85 22:19:19 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 8 APR 85 01:18:30 EST
Date: Mon 8 Apr 85 01:17:51-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: tape
To: jk@SU-AI.ARPA, ejg@SU-AI.ARPA, rpg@SU-AI.ARPA
I am sending a tape in the morning. It contains
o local special declarations complete and CL spec (trickier than I had
thought)
o random bug fixes tickled by exercising the special binding code in testing
the above.
o some improvement in handling multiple closures.
This should be a pretty straightforward integration into you current
compiler version.
What needs to happen before I can test any closure stuff is:
EB should write a fastcall for sq-fcons which takes a procedure on the
stack and returns a copy on the stack. I don't have enough of the
module structure here to figure out how to do that.
JIM should make newlap understand closures.
Then if you send me back a tape (also the modules I'm missing) I'll
work on finishing closures next weekend.
-------
∂12-Apr-85 0743 JK Announcement
∂11-Apr-85 0824 RPG Announcement
∂10-Apr-85 1654 HANDERSON@CMU-CS-C.ARPA Announcement
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 16:50:36 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 10 Apr 85 19:50:37-EST
Date: Wed, 10 Apr 1985 19:50 EST
Message-ID: <HANDERSON.12102149104.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Announcement
In-reply-to: Msg of 10 Apr 1985 19:36-EST from Dick Gabriel <RPG at SU-AI.ARPA>
Dick,
I think I yelled it on some mailing list I didn't intend to, but you're welcome
to look at the code. It's in [cmu-cs-c]<handerson.flavors>. I intend
everything to be portable CL.
All I ask is that you consider sharing improvements with me and that you
definitely inform me of any bugs you find - I can't fix what I don't know
about. The kernel is currently broken, but I hope to have a still improved
version available tomorrow.
-- Steve
∂15-Apr-85 0721 JK
∂14-Apr-85 1602 ROD y combinator and bugs
I just now have a working compiler and assembler to play with. The
y-combinator now works, but in testing it on factorial I noticed
that whereas in
(*& 100000 100000)
gace an overflow error and trapped ot the debugger, lucille merely
gives a segmentation fault and dumps core. In making the new error
handler someone must have forgotten to fix &* for it.
∂16-Apr-85 0844 JK misc questions
∂15-Apr-85 1423 boeing@diablo misc questions
Received: from SU-AIMVAX.ARPA by SU-AI.ARPA with TCP; 15 Apr 85 14:23:21 PST
Date: Mon, 15 Apr 85 14:23:40 pst
From: Boeing <boeing@diablo>
Subject: misc questions
To: jk@sail
I talked with Alan Snyder (@HPLABS) regarding a proposal for common lisp
objects, and he mentioned that he had already forwarded a copy of his
proposal to Eric Benson. Could you ask Eric to send me a copy of the
proposal?
Possibly Eric could give me a call regarding objects w.r.t. LCL?
Tony had indicated that a copy of (all the) paperwork that I signed
would be forwarded back to me, so far I don't have a signed copy of
any of the last round of agreements.
Finally, I got several bids on putting in a drivewalast weekend,
these bids are only good for 30days, so I would like to get going
on them asap. Who should I talk this over with?
-steve
PS: I would have probably just called but I forgot my list-of-numbers
this morning!?
-----------
Steve ---
Go ahead and take whichever bid is most convenient --- the view from
from our end is that we have a $2000 lump sum reserved for this purpose.
We can send that money now or after --- in any case, keep your receipts.
I will ask Jan to send you copies of the stuff. I will also ask EB to call
you.
JK
∂22-Apr-85 0749 JK
∂21-Apr-85 2252 ROD bugs and closures
I telephoned in the last binding bug fix to EB who fixed it (I think)
in the compiler. So now you can try bind-test again and it should all
work. One hting that file doesn't test is interactions of local
special declarations and multiple-value-bind.
I have made a lot of progress on closures and can now compile
closure-test (but not assemble it due to the lap bug) all the
way up until you started putting closures as default values for
optional arguments. There is only one other thing I have to
do for bare clsoures--handle a closure inside a tagbody some of
whose bindings are established outside (and imilarly for if).
I plan to do that Monday eveneing and send you a tape tuesday.
It will not include the default argument stuff yet.
Then onto labels etc.
I assume things will end eventually...
∂23-Apr-85 0810 JK closures
∂22-Apr-85 2237 @MIT-MC:BROOKS@MIT-OZ closures
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Apr 85 22:32:31 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 23 APR 85 01:32:48 EST
Date: Tue 23 Apr 85 01:31:28-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: closures
To: jk@SU-AI.ARPA, eb@SU-AI.ARPA
I haven't quite got all the bugs out of the hairy loop sharing closure
case, so I will not sen a tape until Wednesday after working onit again
tomorrow night.
Incidentally, I decided to do it right and am using cons cells to
provide the shared data stucture rather than code-less closures
as was the original hack plan.
-------
∂23-Apr-85 0811 JK
∂23-Apr-85 0700 ROD closures
after my last message I got the hairy loop cases with closures working. I'll
test some more tonight and try to get the closures in optional
defaults working, then send a tape tomorrow.
Incidentally, the multiple-value-bind example is neither a bug in multiple-value-bind
nor in local special declaration hndling. It turns out there has been a bug all
along in the way the let optimizers substitute into a let body such that the
substitution gets ignored when the whole body is getting replaced. I'll fix
that tonight too.
∂23-Apr-85 1938 JK
∂23-Apr-85 1442 ROD multiple valued fastcalls
Jussi,
Please tell Rob Poor that multiple valued fast calls already work.
To define truncate& say, one would do:
(defprimop truncate& 2 2
:pred (fixnump fixnump)
:fast sq-truncate
:effs nil))
The first "2" says it takes two arguments on the stack, and the
second "2" says that it returns 2 arguments. 0.43 1 2 19 42,2012 13,390 3792P 53% 1 12
Also let him know that on entry to a fastcall the arguments are on
the stack and immediately on top of them is a return pc. On exit
the results should start where the first arg was.
Rod
∂24-Apr-85 0743 JK
∂23-Apr-85 2200 ROD tape
A tape with full closures and sundry bug fixes to other things should
arrive at Lucid Thursday morning. I was able to test a few examples
which didn't tickle the assembler bugs and it seem sto do the right
thing for closures inside loops. It certainly compiles all the
examples in closure-test, but I couldn't assemble many of them.
It handles closures in optional and key defaults although that
is not well exercised and may have some bugs lurking.
∂26-Apr-85 0738 JK 370 common lisp
∂26-Apr-85 0705 @MIT-MC:BROOKS@MIT-OZ 370 common lisp
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Apr 85 07:01:31 PST
Received: from MIT-OZ by MIT-MC via Chaosnet; 26 APR 85 10:02:22 EST
Date: Fri 26 Apr 85 09:57:52-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: 370 common lisp
To: rpg@SU-AI.ARPA, jk@SU-AI.ARPA
Intermetrics claims to have a 370 Common Lisp (including compiler).
There is a talk
about it next Wednesday evening. I will go to it. Maybe we should schedule
a similar sort of thing around here about Lucid CL. Dick, can you get in on
whatever series it was you gave the timing talk at and get them to invite you
again?
-------
∂29-Apr-85 0759 JK
∂28-Apr-85 1317 ROD do-all-symbols and performance
To: JLW, EB, JK, RPG
do-all-symbols macro is not defaultly in the compiler.
After I put it there and ran it I discovered it is buggy--it returns a list
with all the symbols, plus a bunch of entries like: (*empty*).
I first tried to run it interpretively, with 0.5meg free space. It GCed
after using 3kbytes of storage for the list--i.e. 99.4% consing overhead
in the interpreter! After 5 minutes I gave up. Compiled it took abouta a
second. This is unacceptable interpreter performance to most people.
∂29-Apr-85 0759 JK
∂28-Apr-85 1336 ROD storage
To: JK, RPG, EB
It occured to me that the arglists stored with each procedure might
be taking up undue amounts of storage, so I started to collect some
statistics. One thing led to another and I obtained the following
puzzling results. I added headers and rounded up to 8 byte multiples
everywhere.
I looked at all symbols, and divieded them into two classes--those
both unbound and unfbound and those which are at least one of those.
Below first column is boht unbound and unfbound. Last column is
all symbols. Row lables are:
n: number of symbols in this category
proc: bytes devoted to procedure headers
argl: bytes devoted to arglist cons cells
code: bytes devoted to code vectors
symb: bytes devoted to symbols themselves
pnam: bytes devoted to print names
totl: total number of bytes
n | 1567 | 2168 | 3735 |
---------------------------------
proc | 0 | 79048 | 79048 |
argl | 0 | 28264 | 28264 |
code | 0 | 688328 | 688328 |
symb | 37608 | 52032 | 89640 |
pnam | 28008 | 48040 | 76048 |
---------------------------------
totl | 65616 | 895712 | 961328 |
Kahlua binary size: 2798592
GC reports free: 513040
Bytes accounted for: 961328
-------
Unaccounted bytes: 1324224
So that means 1.3Mb burnt on package structures (including obarrays)
and GC tables. Or lost in space somewhere else. Or have I forgotten
some other major piece of storage?
∂29-Apr-85 0801 JK
∂28-Apr-85 1901 RPG Well
To: ROD@SU-AI.ARPA
CC: JK@SU-AI.ARPA, EB@SU-AI.ARPA
The GC reported (as of the version we sent you) the number of
bytes free until a flip was required, so you can effectively
take the amount of dynamic storage you know about, add the amount
that GC reports free, and then double that total for the total
amount of space used by dynamic structures plus the free space.
To figure the amount free, take what the GC reports (= gc-free), what you know
is in dynamic (= known-dynamic) and do:
total+free = 2*(gc-free + known-dynamic) - known-dynamic
= 2*gc-free + known-dynamic
I'm not sure this jives
Using your table, I get:
2*513040+961328+89640+76048 = 21530960
from know stuff. There are a number of free segments for code
and static stuff, which I did not count, and the first 32k is a
wash because of Unix. No GC tables are in dynamic space.
-rpg-
∂29-Apr-85 0801 JK Re: Well
∂28-Apr-85 2039 @MIT-MC:BROOKS@MIT-OZ Re: Well
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 28 Apr 85 20:39:50 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 29 APR 85 00:38:48 EDT
Date: Sun 28 Apr 85 23:39:23-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: Well
To: RPG@SU-AI.ARPA
cc: jk@SU-AI.ARPA, eb@SU-AI.ARPA
In-Reply-To: Message from "Dick Gabriel <RPG@SU-AI.ARPA>" of Sun 28 Apr 85 19:01:00-EDT
I don't completely follow your arithmetic. How about this:
Total space = 2*(gc-free + known-dynamic) + known-code
= 2*(513040+79048+28264+89640+76048) + 688328
= 2260328
(assuming code space doesn't count as dynamic?)
Thats within 0.5Mb.
-------
∂29-Apr-85 0803 JK
∂28-Apr-85 2252 ROD common lisp compiler
To: JK, EB, RPG
I'll send a tape in the morning to arrive Tuesday that includes:
compiler-let, flet, and labels all working completely.
macrolet working modulo two things:
1. It relies on a function turn-macro-into-destructuring-lambda which
takes a form like (macro (x y) (...)) and returns a lambda expression
of one variable which could be funcalled on a form to be macro expanded
and would return a single level of macro expansion under the
sepcified macro. I assume JK will take care of writing this, or changing
the single call to it in alph-special.lisp to the right thing.
2. I havne't added the optional environment argument to compiler-macroexpand,
alpha-macroexpand or macroexpand. This is only needed in the screwiest
of cases (I handle recursive macro expansions over macrolet'ed macros
without it). I'll leave that for someone else to fix. The argument
to seed the environment from alphatize is `lexical'.
I have not actually tested macrolet, but it mostly shares code with
flet and labels.
Can you send me a fixed lap sometime?
I'll include my statistics gathering code in a file: gather.lisp
I guess I should next test the errror handling for lost go tags and
lexical blocks from within closures. (And modify the uncaught throw
catcher to do the right things for them.)
∂30-Apr-85 0818 JK
∂30-Apr-85 0210 JLW do-all-symbols
To: ROD@SU-AI.ARPA
CC: JLW@SU-AI.ARPA, EB@SU-AI.ARPA, JK@SU-AI.ARPA, RPG@SU-AI.ARPA
Re your message of 28-Apr-85 13:17
I just tried out the package-macros file in LCOMP, and am getting exactly
the correct behaviour. Could some other bug explain your comment
After I put it there and ran it I discovered it is buggy--it returns a list
with all the symbols, plus a bunch of entries like: (*empty*).
?
Actually, you shouldn't attempt to "run" do-all-symbols in the LCOMP
environment -- only to macroexpand such forms. I did debug it under a
Franz based environment, but it takes a bunch of setups t get the real
package structure there. At any rate, EJG discovered a faslout bug today
(and fixed it) that caused LCOMP to lose badly *ocasionally*; after that
fix, I had no problem just loading in the file package-macros.o into
LCOMP, compiling some code that used do-all-symbols, and then running the
resultant .lbin file ok.
The consiness of the evaluator which you remarked upon has been a subject
of some discussion (and chagrin!) here already.
-- JonL --
∂30-Apr-85 1646 JK
∂22-Apr-85 1209 RPG
∂04-Apr-85 1300 ROD cmu summer hacker
his name is Richard Wallace. rsw@cmu-ri-rover. He works for
Hans and Kanade.
---------
Rod Brooks tells me that you might be interested in a summer job
at Lucid --- any truth in this? If so, could you send a resume
of sorts etc for us to look at?
Jussi Ketonen
Project Manager, Lucid
∂30-Apr-85 1653 JK Lucid and LISP programming
∂22-Apr-85 1128 RPG Lucid and LISP programming
∂21-Apr-85 2254 RIK@SU-CSLI.ARPA Lucid and LISP programming
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 21 Apr 85 22:54:36 PST
Date: Sun 21 Apr 85 22:53:47-PST
From: Rik Sprague <RIK@SU-CSLI.ARPA>
Subject: Lucid and LISP programming
To: rpg@SU-AI.ARPA
Hi,
I'm an instructor for CS122 (LISP programming) this quarter. Just
yesterday, I discovered that I will be staying around Stanford for the
summer, so now I'm looking for a good LISP-type programming job. I
was told that Lucid might be looking for people. Can you tell me who
I might talk to, etc.?
Rik Sprague
-------
Hi,
Lucid is indeed looking for people. In order to proceed we need
(a) a resume
(b) samples of Lisp programming done by you.
Could send us some stuff soon ---- I would like to set up an
interview as soon as possible.
Best Regards,
Jussi Ketonen
Project Manager, Lucid
∂30-Apr-85 1654 JK Lucid & Lisp
∂22-Apr-85 1128 RPG Lucid & Lisp
∂18-Apr-85 1141 shivers@cmu-cs-h.arpa Lucid & Lisp
Received: from CMU-CS-H.ARPA by SU-AI.ARPA with TCP; 18 Apr 85 11:40:53 PST
Date: 18 Apr 1985 14:43:33-EST
From: Olin.Shivers@CMU-CS-H
To: rpg@su-ai
Subject: Lucid & Lisp
Hello. I am a graduate student at Carnegie Mellon University. I'm interested
in optimising compilers for lexically scoped lisps. I've heard about your
company, Lucid, from Scott Fahlman and David Toureztky. It looks like you
have a sizeable fraction of the available lexically scoped Lisp talent
cornered at Lucid. If you have summer positions open for Lisp compiler and
system hacking, I'd be interested.
I've had previous experiences with Lisp implementations. In 1981 I wrote a
throw-away Scheme compiler in Maclisp that targeted into MACRO20 assembly for
a DEC-20. It was a single-person effort, and included full lexical scoping,
environment analysis for code optimisation, and upward funarging.
Last summer, I worked with a group headed by Jonathan Rees on the design and
implementation of version 3 of the T language, and its optimising compiler,
Orbit. The compiler was targeted to the VAX and a RISC processor under
development by DEC. I think you know Jonathan and T.
The Orbit compiler included global register allocation, type analysis,
environment analysis, trace-scheduling code generation, procedure integration,
and representation analysis. It is the most highly optimising lisp compiler
that I know of to date. It is also particularly elegant: almost the entire T
system -- including the compiler, evaluator, garbage collector, loader, system
linker, and assembler -- is written in T. My part of the effort included flow
analysis, language design, runtime internals, and the linker.
I like lexically scoped lisps because -- among other reasons -- of the
leverage they give the compiler for doing powerful optimisations. Seeing Lisp
judged by the example of franzlisp makes me flinch; I'd like to see the world
do better.
A C.V. follows.
-Olin Shivers
-----
Olin Shivers
Computer Science Dept
Carnegie-Mellon University
Schenley Park
Pittsburght, Pennsylvania
(412) 578-7598 Olin.Shivers@CMUA
INTERESTS:
Design and implementation of Lisp, optimising compiler design, search-based
achitectures for intelligent systems, digital circuit synthesis, expert
systems.
EDUCATION:
September 1984 Carnegie-Mellon University
Entered PhD program in the Computer Science Department.
Doing research on search-based computer architectures with advisor
Allen Newell.
Summer 1983 Trinity College, Oxford University
Summer program in English literature and Art History.
May 1983 Yale College
Awarded B.S. Cum Laude with double major in Computer Science and Mathematics.
Strong background in Physics and EE.
Employment:
Summer 1984 DEC Western Research Lab
Member of Jonathan Rees's T3 group. The group designed and implemented version 3
of the lexically scoped lisp, T, and its optimising compiler, Orbit. The
compiler was targeted for the VAX and a DEC RISC processor currently under
development. Worked on flow analysis, language design, runtime internals,
and the linker.
Summer 1982 MIT AI Lab
Worked with Prof. Randy Davis' Hardware Troubleshooting project.
Wrote constraint compiler for DPL implementation language. Designed
language extensions.
Summer 1981 Southwire Co., Carrollton, Ga.
Developed device-independent 2D color graphics packages for business and
engineering applications on Burroughs B6500. Project included hardware
selection, software design, and implementation in ALGOL.
Summer 1980 Southwire Co., Carrollton, Ga.
Developed systems tools for program development on Tandem/16 computer.
Smaller programs included printer servers, and file browsers.
One major program was an interactive screen-oriented forms-design tool that
compiled forms into COBOL source to produce a given transaction form.
Another was a tool that analyzed application programs for references to
system-wide files and structures, and maintained a table of these
references.
Summer 1979 CSTL Engineer Experiment Station, Georgia Inst. of Technology
Minor programming tasks in compiler development project. Administrative
work on Ada language development project. Minor hardware work.
1976-1979 EMS Department, Georgia Inst. of Technology
Programmed part-time for professor. Developed a hidden-surface 3D
graphics system in FORTRAN. Wrote small plotting package on CDC CYBER76
for experimental data. Some numerical analysis in FORTRAN.
∂30-Apr-85 1659 JK Lucid & Lisp
∂22-Apr-85 1128 RPG Lucid & Lisp
∂18-Apr-85 1141 shivers@cmu-cs-h.arpa Lucid & Lisp
Received: from CMU-CS-H.ARPA by SU-AI.ARPA with TCP; 18 Apr 85 11:40:53 PST
Date: 18 Apr 1985 14:43:33-EST
From: Olin.Shivers@CMU-CS-H
To: rpg@su-ai
Subject: Lucid & Lisp
Hello. I am a graduate student at Carnegie Mellon University. I'm interested
in optimising compilers for lexically scoped lisps. I've heard about your
company, Lucid, from Scott Fahlman and David Toureztky. It looks like you
have a sizeable fraction of the available lexically scoped Lisp talent
cornered at Lucid. If you have summer positions open for Lisp compiler and
system hacking, I'd be interested.
----------------
Yes, we would be very interested.
When could you come and how long can you stay?
Do you have a phone number where we could reach you?
Also: Phone number(s) of any references for you.
Best regards,
Jussi Ketonen
Project Manager, Lucid
∂01-May-85 0754 JK Re: analyze-primop
∂30-Apr-85 2200 @MIT-MC:BROOKS@MIT-OZ Re: analyze-primop
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Apr 85 22:00:09 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 1 MAY 85 00:58:54 EDT
Date: Wed 1 May 85 00:58:24-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: analyze-primop
To: JK@SU-AI.ARPA
In-Reply-To: Message from "Jussi Ketonen <JK@SU-AI.ARPA>" of Tue 30 Apr 85 18:57:00-EDT
Sounds like a good fix. I suspect this never mattered in the pre-EB
tail days and everything worked out fine. Make sure I get a copy
of the fixed file sometime.
-------
∂03-May-85 0831 JK 370 CL
To: FTL, JLW
∂01-May-85 2127 @MIT-MC:BROOKS@MIT-OZ 370 CL
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 May 85 21:27:41 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 2 MAY 85 00:18:57 EDT
Date: Thu 2 May 85 00:19:26-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: 370 CL
To: jk@SU-AI.ARPA, rpg@SU-AI.ARPA
I went to the Intermetrics 370 Common Lisp talk tonight.
They are pretty much babes in the woods.
They are porting SPICE, including the compiler. 2 people have been
working 5 months on the compiler. I believe others are working on
other aspects as a GC question was deferred to someone at the
back of the audience.
They are running under cms/vm. They use the top eight bits for tags.
They use excess 2↑23 fixnums.
They write protect a page at the top of the heap(s) so that a write
violation signals GC time, in order that cons need do no checking in
line. They have two fixed size heaps to copy between.
Call is 3 args in regs, arg count in R0, and rest of args on the
stack in the callee's frame. Single value gets returned in the
register.
They snap links for speed. Normal funciton calls go via a pondering
routine which decides whether the callee is interpreted etc.
They do tail calls as jumps.
Multiple values are always consed into a heap vector. They look back
on the stack an arbitrary number of frames to see if multiple values
were expected first however. They haven't yet decided how to do either
catch, throw or unwind-protect.
They make generic plus and minus fast in the case everything is
actually a fixnum. Their tags are chosen such that if you add two
things and get a fixnum then both arguments must have been fixnums. So
they only exececute four instructions (out of six generated) if
generic plus gets two fixnums.
They associate access funs with every array.
Every call to a closure does consing to set up the lexical environment
to look like what the interpreter would have done.
-------
∂03-May-85 0831 JK gold hill
∂01-May-85 2158 @MIT-MC:BROOKS@MIT-OZ gold hill
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 May 85 21:58:06 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 2 MAY 85 00:58:12 EDT
Date: Thu 2 May 85 00:58:43-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: gold hill
To: jk@SU-AI.ARPA, rpg@SU-AI.ARPA
Jerry Barber was at the talk tonight (he is giving next month's). He told
me that he and Nick Gall have just finished a compiler. Beta test in
two weeks and market in August.
-------
∂03-May-85 0832 JK generic arithmetic
∂01-May-85 2200 @MIT-MC:BROOKS@MIT-OZ generic arithmetic
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 May 85 21:59:51 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 2 MAY 85 01:00:27 EDT
Date: Thu 2 May 85 01:00:54-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: generic arithmetic
To: ejg@SU-AI.ARPA
cc: jk@SU-AI.ARPA, rpg@SU-AI.ARPA
Here are some thoughts on generic arithmetic. You've probably thought
of most of these already but maybe there's something new. (EB told
me about the OR trick tonight.)
I think it extremely important that generic plus and minus turn out
to be fast in the case that both arguments are fixnums and the result
is a fixnum. I think that will capture 99% of all generic arithmetic
of a large class of users. I think it is worth sacrificing
portability of the code to implement this part of generic arithmetic
and redo it for every machine.
Thus generic plus and minus should be open coded with a call (or more)
to fixup routines for the non fixnum cases.
Since all arithmetic operations besides 32 bit plau and minus have to
be handcoded anyway I don't think we should worry about this
introducing a few new fastcalls.
Consider just plus. There are special things you can do for each of
the following cases:
a. (+ x y)
b. (+ x 5)
c. (+ x 5.0)
d. (setq x (+ x 7))
Likewise there will be 4 cases for - and 3 for reverse -.
In case b the testing sequence is quicker. In case c it is non
existent. Case d. is currently hacked into the compiler for
+& and -&. It does these directlyu on the stack. Maybe it can't
be done right generically because of overflow and not being
able to get x back.
The real problem is that arithmetic with overflow protection begs
to be done in dreg's, but once you've got things there and discover
they are not fixnum's you had better get the originals from their
markable locations to send to the fixup routine, due to GC's. Havuing
to get things twice kills code density.
One possibility is to insist on args in the aregs (i.e. a0 and a1)
and have the fixup routines expect args there and promise to deliver
in a0. With suitable reordings in the optimizers things like
(+ x y z (- d e)) would get chained into operations using a0 as
an accumulator.
Here's a code seqence then:
(move a0 countreg)
((move w) a0 scratchreg)
((or w) a1 scratchreg)
((and w) (word-constant 3) scratchreg)
((branch eq) ok)
(fastcall sq-+)
(jmp done)
ok
(add a1 countreg)
((branch vc) done) ; branch no overflow--codegen needs to learn these cc's
(fastcall sq-overflow-+)
done
I think fastcalls are two instructions meaning 12 instructions, 7 of
which get executed in the average case. THe word instructions might
be more efficient as byte instructions but I don't remember. Depending
on relative costs of branch/no-branch this might be made tenser too.
-------
∂03-May-85 0833 JK More arithmetic
To: FTL, JLW
∂02-May-85 0900 @MIT-MC:BROOKS@MIT-OZ More arithmetic
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 May 85 09:00:27 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 2 MAY 85 11:58:58 EDT
Date: Thu 2 May 85 11:45:48-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: More arithmetic
To: ejg@SU-AI.ARPA
cc: jk@SU-AI.ARPA, rpg@SU-AI.ARPA
I bet d4 and d5 never get used in regular code. The code sequence I
sent last night could be tightened if there were some markable data
registers, as for the fixnum case you'd like the things to
be in data registers, but they also must be markable.
(Actually I missed one instruction last night--to put the answer back
in a0. That made it 8 instructions in the common case.)
So perhpas one could make d4 and d5 a new class of registers --call
them nreg's for number registers, or even two new classes each with
just one register in it; e.g. nrega and nregb. This would require
no change at all to the compiler, just a change to *registers*.
Primops could reuest args in an nrega (if which there'd be only one
anyway) and an nregb, and pass back there result in one of their
argumnets whioch would always turn out to be the nrega (i.e. d4).
Before doing this one would have to chack all existing runtimes
(especially *&) to make sure they don't put unmarkable things in d4
or d5. I don't know whether this would uncover any insoluble problems.
The link to the GC would have to be changed to make sure it thought
that d4 and d5 were markable too.
So now the code sequence, after argument set up in d4 and d5, becomes
((move w) d4 scratchreg)
((or w) d5 scratchreg)
((and w) (word-constant 3) scratchreg)
((branch eq) ok)
(fastcall sq-+)
(jmp done)
ok
(add d5 d4)
((branch vc) done) ; branch no overflow--codegen needs to learn these cc's
(fastcall sq-overflow-+)
done
And the result is in d4. That's 6 instructions executed when things
turn out to be two fixnums. The overhead of getting things into
d4 and d5 is no worse (in fact slightly better) than pushing things on
the stack for a regular fastcall, and much better than for a regular
procedure call.
Now sq-+ etc. expect their args in d4 and d5 and return in d4.
Optimizers can change argument orders and introduce reverse-minus,
so that a chain of operations make use of d4 as an accumulator.
All of the above is pretty minimal changes for 6 instruction generic
arithmetic adds and subtracts in the most common case.
It may even pay to make all numeric fastcalls obey this convention
and go through the compiler and add a new sort of procedure call--
an arithcall (we already have three classes; inline-primop, fastcall
and full-procedure-call).
-------
∂03-May-85 0835 JK GCs
∂02-May-85 0902 @MIT-MC:BROOKS@MIT-OZ GCs
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 May 85 09:02:22 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 2 MAY 85 12:01:44 EDT
Date: Thu 2 May 85 11:53:50-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: GCs
To: jlw@SU-AI.ARPA
cc: eb@SU-AI.ARPA, rpg@SU-AI.ARPA, jk@SU-AI.ARPA
I think the biggest determining factor on GC choice for the next two years
or so (i.e. until every sun user has gobs of physical memory) will be compaction
and GC time paging. I suspect the only way we will be able to get a good handle
on those for any particular GC strategy is to implement it and benchmark like
crazy. So my vote is to try both the ref count and the one I've just suggested
as soon as we get breathing time to do it. The one advantage of my suggestion
is that it woud take EB and RPG about a day to fully implement it and
try it out, (as it really does hardly anything different from at the moment,
just reorders thing sin time a little). Thus it might provide a short-term
quick performance improver while we can do a hairer system over the longer
period of time it will take.
-------
∂06-May-85 1028 JK tape
∂05-May-85 2254 @MIT-MC:BROOKS@MIT-OZ tape
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 22:54:43 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 6 MAY 85 01:55:20 EDT
Date: Mon 6 May 85 01:55:47-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: tape
To: jk@SU-AI.ARPA, rpg@SU-AI.ARPA
I am sending you a tape with the improved recursion, 'fast option,
and bug fix for the case of closures Chris Wright tickled.
The closures still do too much consing sometimes. I have a scheme to
make it all good by removing the s-1 style closures and using only
shared cons cells (the copy-procedure can be delayed till the last
minute in that case), which will get around all the problems you
have observed. I'll do that next weekend.
----
Change subject.
I suspect a straight forward interpreter with an association list
for an environment would be much better the current set up--sure it
would do consing for variable binds, but nothing like the current
set up. Also having the code disappear is most upsetting. People like
to look at the code with symbol-function. If you have
anything like the current situationI predict we will lose big. People
will not like it--they will try it and claim it is totally bogus. They
will be correct.
-------
∂06-May-85 1032 JK Re: some to be done's
∂05-May-85 1644 @MIT-MC:BROOKS@MIT-OZ Re: some to be done's
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 16:44:01 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 5 MAY 85 19:41:15 EDT
Date: Sun 5 May 85 19:41:42-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: some to be done's
To: JK@SU-AI.ARPA
In-Reply-To: Message from "Jussi Ketonen <JK@SU-AI.ARPA>" of Sun 5 May 85 16:02:00-EDT
(1) I'll try. I can make multiple-value-call quite good in the case
that there is only one ``argument form'' (it might produce multiple
values of course). More than one form and multiple-value-prog1 are
both tough because the compiler expects to know the stack height all
the time, so the values can't be stashed on the stack....
(2) I'd like to see the source of Chris's code to know just what is happening.
It is not necessarily true that all closures are consed on entry to a
function. (I don't understand the reference to acons at all--according
to my manual it is written (defun acons (x y a) (cons (cons x y) a)).)
(page 279)
[(3) Maybe Chris should write better code. Closures are never going
to be free.]
-------
∂06-May-85 1033 JK
∂05-May-85 1602 JK some to be done's
To: ROD@SU-AI.ARPA, JK@SU-AI.ARPA
(1) We don't yet have multiple-value-prog1 and multiple-value-call
in the compiler other than as compiler macros.
These should be done somewhat better
(2) Chris wrote member and assoc using closures and special casing
eq. The result was an incredibly slow acons; when the body
of the function is entered, apparently all closures are consed
regardless whether they are used. Is it possible to improve
this somewhat?
∂06-May-85 1040 JK Re: some to be done's
∂05-May-85 1644 @MIT-MC:BROOKS@MIT-OZ Re: some to be done's
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 16:44:01 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 5 MAY 85 19:41:15 EDT
Date: Sun 5 May 85 19:41:42-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: some to be done's
To: JK@SU-AI.ARPA
In-Reply-To: Message from "Jussi Ketonen <JK@SU-AI.ARPA>" of Sun 5 May 85 16:02:00-EDT
(1) I'll try. I can make multiple-value-call quite good in the case
that there is only one ``argument form'' (it might produce multiple
values of course). More than one form and multiple-value-prog1 are
both tough because the compiler expects to know the stack height all
the time, so the values can't be stashed on the stack....
(2) I'd like to see the source of Chris's code to know just what is happening.
It is not necessarily true that all closures are consed on entry to a
function. (I don't understand the reference to acons at all--according
to my manual it is written (defun acons (x y a) (cons (cons x y) a)).)
(page 279)
---------------
I meant assoc; chris's assoc falls into closure stuff after
it has done eq tests on #'eql; otherwise assq is called.
[(3) Maybe Chris should write better code. Closures are never going
to be free.]
-------
∂06-May-85 1040 JK CL bogosity
∂05-May-85 2247 @MIT-MC:BROOKS@MIT-OZ CL bogosity
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 22:47:24 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 6 MAY 85 01:46:26 EDT
Date: Mon 6 May 85 01:46:53-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: CL bogosity
To: jk@SU-AI.ARPA
cc: rpg@SU-AI.ARPA, eb@SU-AI.ARPA
Jussi,
I tracked down the problem with the go out of a closure and the
bug turns out to be in code you wrote! I cc'ed RPG and EB on this
because its resolution involves issues in interpreter semantics
and language definition!
The code you had was (defun return13 () (block as ...)). When I
removed the outer block and changed the (return-from as ...)'s to
(return-from return13 ...) everything worked fine--it compiled
and the go out of the closures worked at runtime.
When I tried to compile you code directly I got a message
``named BLOCK not supported''. This is from the Franz block macro.
The problem is that to wrap the implicit return13 block around the
supplied body it is necessary to pull out any declarations first and
put them outside. This is done with JK's code parse-body. Called in
/mods/functions/common/compmacs.lisp. The current
CL definition says that macros can expand to declarations so
parse-body uses macroexpand to macroexpand away at the first forms
before doing the wrapping. Unfortunately macroexpand in the compiler
is the wrong thing (should be compiler-macroexpand) as it gets the
host's macro definitions.
[I am slightly confused--earlier in the file you had similar block
constructs. If I compile them they barf. I assume you can compile
them, otherwise you would have complained. Therefore I guess you must
be using the 3600, and somehow its block macro ddidn't screw you
on those cases, but who knows what code you were compiling and
testing...]
Where does interpreter semantics come in? Well I think the current
setup (/mods/controlmacro/definers.lisp for the interpreter) which
does the same deal is wrong. Any macro which happens to be at the
start of a code body is currently getting expanded only once
(unless Jussi you are unrolling if there is no declare, but in that
case there will be a macro expansion both at defun time and run time),
and further more consider this case:
(defun frotz () (declare (special x)) x)
(defun foo (x) (declare-macro x) (frotz))
(defmacro declare-macro (var) `(declare (special ,var)))
(defun bar (x) (declare-macro x) (frotz))
which should give different results for foo and bar under the current
scheme. [I tried it and they actually both give the same bizzarely wrong
results and the results change the second time you try it---the
current interpreter seems unuseable to me with the compiling crap.
You can't even see the lisp code and it changes out from under you.]
...so I don't understand what is currently happening in the
interpreter but it will be hard to fix in any case.
As it happens this has been the subject of an all day debate on the
CL mailing list today. Most people seem in favor of flushing the
ability of macros to expand to declares, due to the gross inefficieny
it causes in interpreters that do it right (have to memoize the
first call, or not make the implicit block explicit, or something).
I recomend flushing this feature from LCL, and voting in the current
debate to have it flushed. I will have to change one place in the
compiler too.
As for the more immediate problem of making your example work, Jussi,
I guess you have to somehow signal to parse-body to use the
compiler-macroexpand, maybe by checking in parse-body whether the
*inside-the-compiler* switch is set.
Rod
-------
∂07-May-85 1437 JK
∂06-May-85 2346 FY Re: summer jobs
[Reply to message recvd: 30 Apr 85 16:41 Pacific Time]
At this point in time, I'd certainly like to come and talk to you. I
really am not sure whether what I'm looking for is full time work or,
more likely, part time ``consulting'' while I do desparately needed
thesis catchup work.
Should I call you to arrange sometime convenient for me to come by?
Thanks.
-- Frank
------------
Yes. I was thinking in terms of full time for the summer, but there
may be other possibilities.
∂07-May-85 1438 JK
∂04-May-85 2145 ROD improved compilation
To: RPG, JK, EJG, EB
I have just done two things to the compiler:
1. Made it smarter about code for a recursive call to self in
a non-tail position, when the function takes a fixed number of
arguments. Cuts the function call overhead from 12 to 6 instructions
executed.
2. Added an option 'fast which generates fixed number of argument
function entries with no arg count checking. This takes two
instructions off (of execution). It should only be used when you
know the program is correct. (RPG's message to SUN prompted
me to think about this one.) You might try compiling the GC with this
option on (but make sure the user interface functions don't get compiled
this way), and any other time critical pieces of lisp code.
This option has no effect when case 1 above is happening.
I tried this out on tak, and used my watch to time it over ten runs.
I consistenly got 1.85 secs. This compares to 2.26 before, 2.35 for
Franz with all the stops out, and 1.44 for PSL. In looking at the code I can't
see how to get closer to PSL without passing args in regs rather than on the
stack. (the 'fast option saves a total of two instructions being executed
for the whole of (tak 18 12 6) in this case...)
It's probably worth running the benchmarks through again,
with and without the fast option (e.g. the
fast option will help TAKR, but 1 above will not)
∂07-May-85 1900 JK
∂07-May-85 1427 JK
∂06-May-85 2346 FY Re: summer jobs
[Reply to message recvd: 30 Apr 85 16:41 Pacific Time]
At this point in time, I'd certainly like to come and talk to you. I
really am not sure whether what I'm looking for is full time work or,
more likely, part time ``consulting'' while I do desparately needed
thesis catchup work.
Should I call you to arrange sometime convenient for me to come by?
Thanks.
-- Frank
------------
Yes. I was thinking in terms of full time for the summer, but there
may be other possibilities.
∂07-May-85 1900 JK trip
∂07-May-85 1456 @MIT-MC:BROOKS@MIT-OZ trip
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 May 85 14:56:09 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 7 MAY 85 17:45:49 EDT
Date: Tue 7 May 85 17:33:42-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: trip
To: rpg@SU-AI.ARPA, jk@SU-AI.ARPA
I have to be at Stanford Tuesday june 4th (afternoon) for JMM's orals. Currently
plan to arrive Sunday eve and leave Tuesday eve. Can hack/whatever at Lucid.
-------
∂07-May-85 2002 JK Re: compiler bug
∂07-May-85 2001 @MIT-MC:BROOKS@MIT-OZ Re: compiler bug
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 May 85 20:00:58 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 7 MAY 85 22:58:49 EDT
Date: Tue 7 May 85 22:57:50-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: compiler bug
To: RPG@SU-SCORE.ARPA
cc: jk@SU-AI.ARPA
In-Reply-To: Message from "Dick Gabriel <RPG@SU-SCORE.ARPA>" of Tue 7 May 85 01:53:33-EDT
This was not a subtle bug. Every time the value of a multiple-value-bind
clause is let bound to a variable it puts it in the wrong place. I guess
we've been lucky up until now...
In anal-dispatch.lisp there is a function label-destinations with a big
cond dispatch. In the case ((eq type 'multiple-value-bind) there
is
(if (eq 'stacktop wantloc)
`(frame ,(%anode-stack node))
wantloc)
Change this to:
(if (eq 'stacktop wantloc)
`(frame ,(1+& (%anode-stack node)))
wantloc)
i.e. change the frame location by one.
-------
∂08-May-85 0749 JK Re: compiler bugs
∂08-May-85 0652 @MIT-MC:BROOKS@MIT-OZ Re: compiler bugs
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 8 May 85 06:51:53 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 8 MAY 85 09:50:05 EDT
Date: Wed 8 May 85 09:49:05-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: compiler bugs
To: JK@SU-AI.ARPA
In-Reply-To: Message from "Jussi Ketonen <JK@SU-AI.ARPA>" of Tue 7 May 85 21:14:00-EDT
Maybe should should tell me exactly what you changed
so I can keep my sources in step with yours.
-------
Will send you a tape of the changes; the files that have changed are:
alph-special, alph-lambda, alph-dispatch.
Macrolet now works. We will rip out the macros-as-declarations junk.
∂09-May-85 0656 JK [Guy Steele <gls%AQUINAS@THINK.ARPA>: Macros -> declarations]
∂06-May-85 1047 @MIT-MC:BROOKS@MIT-OZ [Guy Steele <gls%AQUINAS@THINK.ARPA>: Macros -> declarations]
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 May 85 10:47:21 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 6 MAY 85 13:46:40 EDT
Date: Mon 6 May 85 13:45:17-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: [Guy Steele <gls%AQUINAS@THINK.ARPA>: Macros -> declarations]
To: jk@SU-AI.ARPA
Received: from MIT-MC by MIT-OZ via Chaosnet; 6 May 85 11:47-EDT
Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 11:47:14 EDT
Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85 08:45:14 PDT
Received: by THINK.ARPA with CHAOS id AA14271; Mon, 6 May 85 11:43:25 edt
Date: Monday, 6 May 1985, 11:43-EDT
From: Guy Steele <gls%AQUINAS@THINK.ARPA>
Subject: Macros -> declarations
To: common-lisp@sail
Cc: gls%AQUINAS@THINK.ARPA
Message-Id: <850506114342.2.GLS@DESIDERIUS.THINK>
I would be not at all unhappy if this feature were to go away.
I agree that Scott's assessment that it is unlikely that any
existing code (outside of diagnostic tests for this very feature)
would be harmed.
I am persuaded not at all by the argument that it is hard to implement.
I am mildly swayed by the efficiency considerations for the interpreter.
The convincing point to me, however, is that the facility is likely
to confuse macro-writers (who do, indeed, frequently find it necessary
to find the division point between declarations/documentation and body).
As a proposal separate from the question of eliminating the expansion
of macros into declarations, I suggest the following primitive
for consideration:
PARSE-BODY list
The list is treated as a body (a list of forms) that may have declarations
and a documentation string at its head.
Three values are returned. The first is some tail of the list,
the executable part of the body. The second value is a list
of declarations (lists whose car is DECLARE) at the head of the body.
The third value is the documentation string, or NIL if there was
no documentation string.
--Guy
-------
∂16-May-86 0807 JK olin shivers
∂15-May-85 1952 FAHLMAN@CMU-CS-C.ARPA olin shivers
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 May 85 19:52:14 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 15 May 85 22:50:49-EDT
Date: Wed, 15 May 1985 22:50 EDT
Message-ID: <FAHLMAN.12111346026.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Jussi Ketonen <JK@SU-AI.ARPA>
Subject: olin shivers
In-reply-to: Msg of 15 May 1985 20:24-EDT from Jussi Ketonen <JK at SU-AI.ARPA>
Jussi,
I've never worked with Olin, so the following is based on just a few
conversations and looking at some stuff he has done. I would hate to
think that what I say is going to be decisive, since it is based on
superficial interactions. Please check with people he has actually
worked with Olin to get the real scoop -- I assume he has given you some
names. OK, so much for disclaimers...
I think that Olin is very good technically. He has knocked off his
quals here easily. He has done a fair amount of work in T Lisp and my
impression is that he produces excellent, well-designed code at a good
rate (though I've only seen a few small samples). He is very
self-confident in technical matters, and would probably not be afraid to
tackle some truly evil problem for you.
He taught a Lisp mini-course here and decided to teach it like a Yale
course: make it VERY difficult, tell people up front to expect that, and
give all the survivors a good grade. I think only one person dropped
out and the others, after bitching all term, gave him very high feedback.
Personally, I think Olin would be pretty abrasive to work with, though
not too bad just to have around. I don't think it ever occurs to him
that he might be wrong about something or that some opposing position
might have merit. I haven't hung around Lucid enough to know whether
this would "fit in", but I doubt it. He wouldn't be disruptive, but I
don't think he'd be just one of the gang.
The bottom line is that I think he could be of real value to you working
alone on some really tough problem, or perhaps working with one other
person if that person is sufficiently high-powered and assertive. I
wouldn't give him anything too routine to do. I would not team him with
anyone who is not first-rate, and would certainly not put him into a
group where he would be a small cog implementing someone else's design.
Olin might tend to mellow over time, once he decides he doesn't have
to prove himself to everyone on a daily basis, so getting your hooks
into him early could be a good investment.
-- Scott
∂23-May-85 1612 JK
∂23-May-85 1109 ROD status
Jussi,
Here's waht I plan to work on next:
1. tailmerging of arbitrary function calls (e..g foo calls
bar in a tail place).
2. open codeing funcall and maybe apply.
3. error handlers for incorrect go's and return-from's out of
lexical closures.
4. figuring out better when a progv is only returning a single
value, and so tightneing up the generated code considerably.
EB thinks that 1 and 2 will have significant impact on the interpreter
and on faslin.
The window inspector seems a constant distance away--maybe you should
put someone in Palo Alto onto it to guarantee it for IJCAI.
Rod
------------------------
Sounds great; maybe you should continue working on the compiler for the
foreseeable future. Other items that we have to address on this line
are:
(1) Register allocator --- we need this for non-68k machines
(2) Peep hole optimizer
(3) PDL's for floats, in case we decide to get serious about this.
Might interact with some TNBIND'sh thing.
∂23-May-85 1613 JK
∂23-May-85 1455 ROD potential summer employee
To: RPG, JK
Patrick Sobalvarro is looking for a summer job.
He is an undergrad, a lab employee, and works at Terrapin
part time. He has written most of the good Logo systems
that are around.
He would like to earn on the order of 10k for the summer.
Mail to PGS@mit-mc if interested in more details.
(He is not a undergrad age--he came back to school
recently after hacking for a while.)
----------------
Would you recommend him?
How good of a Lisp hacker is he?
Would he fit in with the rest of us?
∂23-May-85 1619 JK compiler
To: ROD@SU-AI.ARPA, FTL@SU-AI.ARPA
Some other issues:
(1) The tail recursion removal should be done under some flag---
speed/safety switches in common lisp (eb has some ideas here, I understand)
(2) Perhaps most important from the point of view porting is
removing extraneous dependencies on 68k from codegen.
∂07-Jun-85 1515 JK summer jobs
∂30-May-85 0651 @MIT-MC.ARPA:PGS@MIT-OZ summer jobs
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 29 May 85 20:07:03 PDT
Received: from MIT-OZ by MIT-MC via Chaosnet; 29 MAY 85 23:07:49 EDT
Date: Wed, 29 May 1985 23:08 EDT
Message-ID: <PGS.12115019341.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To: Jussi Ketonen <JK@SU-AI.ARPA>
Subject: summer jobs
Hi. I would indeed be interested in a summer job at Lucid. I'm currently
working at the AI Lab and wondering how I'm going to pay next year's tuition
on what MIT pays its research staff. I'm including a copy of my resume
below.
I'm just finishing a major project for Terrapin. Allowing two weeks of slop
for extraordinary occurrences, I'd be able to start on July 1, and I'd have
to come back to school here around September 11. I'm not too sure what
people do when they work for a summer, not having done that much, so I don't
know if that's too short a period. Certainly I can imagine doing useful work
in that period.
As to interests, well, I'm thinking of doing a thesis on language design for
highly parallel machines, but I haven't done any work in that area yet and
you're a Common Lisp company, so I don't know how much that counts for. I've
done things like write interpreters and storage management stuff like garbage
collectors, and I'd be happy to do anything along those lines. Rod tells me
that your implementation is pretty much written, though, so I'd be interested
in working on just about anything you've got; for example, if you needed
something along the lines of DEFSYSTEM, to supplement this module stuff
that's in Common Lisp, I could do something like that in part of the time I
was there, or if you have dead bears lurking in your code (like if you've
always planned to rewrite your fasloader or the package system, or whatever),
I could do stuff like that. I'm pretty flexible -- I would even be willing
to work on interfacing to various operating systems (although I don't feel as
enthusiastic about that).
Because I have to go back and forth a lot between Terrapin and MIT right now,
it might be hard to reach me on the phone. My home number is 864-4049; my
MIT office number is 253-5834, and I can be reached at Terrapin at 492-8816.
I'm usually at Terrapin at night. All these are in area code 617.
Here's my resume:
PATRICK G. SOBALVARRO
1010 Massachusetts Avenue Apt. 1B
Cambridge, Massachusetts 02138
Home: (617) 864-4049
Work: 253-5834
Born July 21, 1959
Citizenship: U.S.
Career objective: research in artificial intelligence
EDUCATION
1984- MASSACHUSETTS INSTITUTE OF TECHNOLOGY CAMBRIDGE, MA.
Continued undergraduate education. I am currently a senior in
computer science. Courses taken include the graduate core
courses in programming languages, computer architecture, and
artificial intelligence.
1977-1979 MASSACHUSETTS INSTITUTE OF TECHNOLOGY CAMBRIDGE, MA.
Two years as undergraduate in mathematics. Courses taken include
mathematical logic, recursion theory, mathematical analysis.
Extracurricular activities include: chairman of student steering
committee (CICDO) of the Experimental Study Group, 1977 - 1978;
staffer on Nightline, the MIT student peer help service, 1978 -
1979; member of Judo Club, 1977 - 1979.
1973 - 1977 EPISCOPAL CATHEDRAL SCHOOL SANTURCE, P.R.
Valedictorian; Student Council President; National Honor Society;
National Merit Scholar, 1977.
EXPERIENCE
February 1982 - present
Research specialist, MIT Artificial Intelligence Laboratory.
Designed and implemented an innovative control system for the
Unimation Puma 600 industrial robot arm, in PDP-11 assembly code
and Lisp Machine Lisp. This robot control system was, to the
best of our knowledge, the first ever to work over a local
network. Systems programming for various operating systems: ITS,
an operating system for the PDP-10; MINITS, an operating system
for PDP-11s. Occasionally worked on maintenance of the Lisp
Machine operating system. Did maintenance, configuration, and
installation of Chaosnet and Ethernet hardware; supervised
technicians in installation and testing of Lisp Machines.
! - 2 -
September 1981 - January 1982
Software engineer, Terrapin, Inc. Worked on readying MIT's Logo
for the Apple II for market.
March 1980 - August 1981
Sponsored research staff programmer/engineer, Logo Group, MIT
Artificial Intelligence Laboratory. Worked on the implementation
of the Lisp-like programming language Logo for the Apple II, in
6502 assembly code. I also wrote for this version of Logo a
screen editor implementing a subset of Emacs.
CONSULTING
June 1984 - June 1985
Designed and implemented a portable Logo interpreter, written in
C, for Terrapin, Inc., of Cambridge, Massachusetts. This is the
most ambitious implementation of Logo by anyone to date; it
includes a copying garbage collector, arrays, strings, streams,
immediate fixnums, and optimal tail-recursion optimization (Logo
is a parsed Lisp-like language with dynamic scoping; determining
when tail-recursion optimization is possible can be difficult).
It currently runs under Unix, on the Apple MacIntosh and on other
personal computers.
June 1983 - March 1985
Designed a Logo interpreter for Itautec of Sao Paulo, Brazil, and
travelled to Brazil three times over a period of about a year to
teach and supervise its implementation by a team of programmers.
The interpreter runs on Itautec's own Z80-based personal
computer.
BACKGROUND
I was born in El Salvador, and grew up in Puerto Rico. While
Spanish was my first language, I have native-speaker fluency in
English.
I have experience programming in Lisp, many other high-level
languages, PDP-10, PDP-11, 6502, and Z80 assembler.
INTERESTS
Some of the problems I find interesting currently are the
implementation of Lisp and Lisp-like languages, and the
implementation of operating systems.
My other interests include: sports cars, backpacking, travel, and
modern British poetry.
! - 3 -
References will be provided upon request.
!
∂11-Jun-85 1758 JK
Dear Pat --
This is to confirm our conversation last week. Lucid will
pay for your airfare and $3500 a month for a period starting
July 1 and ending approximately September 15.
It seems that we would like you to work on our Common Lisp
interface to window systems; currently we are planning on a two-track
approach: First, a fairly quick job using SUN windows and
foreign function calls. Secondly, a more Lisp-like system with
several levels of window-manipulation primitives. It would
be nice if the first approach would not be completely throw-away.
The first goal is necessary for IJCAI and several AI companies who
want to put up their system ASAP. We would like to approximate
Interlisp-D functionality for window systems, as specified in
section 19 of the Interlisp-D manual. Another nice reference
to look at is the SUN windows manual. If you would like to
study these issues in advance, we could send copies of the
relevant materials. I would like you to work on this system
together with Zach Smith, a new addition to our full-time
technical staff. He has quite a bit of experience in C and graphics,
but none in Lisp.
Best regards,
Jussi
∂13-Jun-85 0746 JK
∂12-Jun-85 2116 @MIT-MC.ARPA:PGS@MIT-OZ
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 21:16:13 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 13 JUN 85 00:15:07 EDT
Date: Thu, 13 Jun 1985 00:12 EDT
Message-ID: <PGS.12118700936.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To: Jussi Ketonen <JK@SU-AI.ARPA>
In-reply-to: Msg of 11 Jun 1985 20:57-EDT from Jussi Ketonen <JK at SU-AI.ARPA>
That's my understanding of our agreement, except that I may have to leave
just a bit earlier -- I believe school starts here on September 11th. I'll
check on that. I'm also still considering driving out there -- were I to do
that, could I present gas receipts, or something? My car is a Datsun; it
ought to be reasonably gas-economical, and probably cheaper than airfare.
Working on a window system sounds fine to me. There aren't any SUN or
Interlisp-D manuals around here, and I would like to look at them as soon as
possible, so copies of the relevant sections would be great.
Incidentally, do you have flavors, or some sort of hierarchical object-
oriented class system? I'm not religious, I was just wondering what the
implementation technology for the second-level (more Lisp-oriented) window
system would be.
----------------
Driving out here is fine, too. Keep some set of receipts (lodging, gas, etc)
so we can justify it in our books. My only concern here is time --- you will
be here July 1st, right?
I'll try to get some documentation asap --- we expect to have flavors in
about 6 months.
JK
∂13-Jun-85 0750 JK declaration pervasiveness.
∂12-Jun-85 1704 @MIT-MC.ARPA:BROOKS@MIT-OZ declaration pervasiveness.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 17:04:32 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 12 JUN 85 19:46:52 EDT
Date: Wed 12 Jun 85 19:44:14-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: declaration pervasiveness.
To: common-lisp@SU-AI.ARPA
cc: jk@SU-AI.ARPA
I'm having trouble deciding exactly how pervasive certain declarations
are. For instance:
(defun f (n)
(flet ((f (m) (* m m)))
(declare (ftype (function (integer) integer) f))
(declare (notinline f))
(+ (f n)
(flet ((f (m) (bar m m)))
(f n)))))
By analogy to type it would appear that the ftype declaration applies
to the call to the (* m m) f, but not to the (bar m m) call. There is
specific language in the first paragraph of page 159 that implies
that. However notinline , which has precisely the same language
applied to it at the top of page 160, is earlier singled out has
having nothing to do with bindings and being pervasive on page 155.
So does the notinline apply to the call to the (bar m m) version or
not? If not, then page 155, and the notion of pervasiveness seem
misleading.
-------
∂13-Jun-85 0254 @MIT-MC.ARPA:BROOKS@MIT-OZ done
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 02:46:55 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 13 JUN 85 05:46:59 EDT
Date: Thu 13 Jun 85 05:44:21-EDT
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: done
To: jk@SU-AI.ARPA
Well the sun is shining here, but I think I'm done sort of.
Read the file install--it includes some documentation on handles into
the environment structure. Also logger and bugs contain bits and pieces.
There are 13 files to be integrated at LIHQ (plus a back up of the old
closure code in case we panic and fall back to that).
All declarations and proclamations re now handled, as is `the' and
`locally'. I have observed it not inline code CAR, and infer that
in (declare (type fixnum a b)) (if (>& a b) a b) the if always returns
a fixnum. (With no AND in the type mind you!)
There is one known problem (CONS and some other insist on inline coding--
I'm sure the fix will be quit localized in the analysis phase and you
can wait a few days for it.)
I have not had a chance to do two much testing. Also the data base
is not complete (in the fdesc's). Additionally by the time I load
all my patches in there is so mauch dynamic space gone, things
become fairly slow.
I'll be in my office late afternoon if you want to talk. I'll send
the tape out today.
-------
∂13-Jun-85 0751 JK
∂12-Jun-85 1320 ROD jump bug?
Breaking the function up into smaller pieces fixed it. I eyeballed
the lap code and transformations and it all seemed ok, so I suspect
the assembler or loader. I will include the big version of the function
on the tape.
∂17-Jun-85 0807 JK
∂16-Jun-85 2347 ROD progress
I have:
o fixed some constant folding bugs EB pointed out.
o realized that we don't need to propagate types across let vars
in the short term at all--even for the primop case as there will
be no opitmization to be done there.
o hacked on getting ignore to work right. I've made changes in 8 files
already, and 2 more to go.
I can't do anymore tonight. My current plan is to finish it Tuesday
evening so it will be in your hands Thursday morning. EB tells me
beta test has slipped a week--I hope that is accurate.
I will also fix the cons not compiling out of line problem on
Tuesday.
∂21-Jun-85 0951 JK tape
To: ROD@SU-AI.ARPA, FTL@SU-AI.ARPA
Have integrated your stuff with the little bit of mine
needed and it seems fine.
Will send you a tape today with a binary, compiler directory
and types directory.
(1) Had to change subtypep considerably since t no longer
contains all types. Also, there is a file called
typedispatch under /functions/utilities. Rewrote
project-type, and-type and or-type.
(2) the files alph-special, anal-tools have changed somewhat
(3) the file anal-procall has changed a lot, check it out
with the examples for dispatch-test.lisp under utilities
loaded in and compiling bind-test.
(4) macrology seems somewhat broken ---- beware of compile.lisp
which eb has also hacked. jonl got some pdl overflows.
∂23-Jun-85 0912 JK
∂22-Jun-85 2023 ROD bignum-decls
To: JLW
CC: JK
There are some bugs in ther version of bignum-decls which JK sent to me.
1. In additive-overflow-p there are two scoping problems with SPOSITION.
First there is ,(1+& SPOSITION), but SPOSITION is not bound at macro
expansion time--it is a variable that occurs in the resulting code.
Second, SPOSITION is used twice in the resulting code in positions
outside of the scope of the let that defines it.
2. In bignum-div-step variable carry-out is bound but unused whereas
borrow-back is used free. I suspect these should have the same name.
3. A bunch of &rest args are called IGNORE and are ignored. They should
have (declare (ignore IGNORE)) done to them.
4. The defconstant for fixnum-bucket-index through macro expanding
bn-temp-bucket-index causes eval to call integer-length&,
but that is not defined in lucille.
There is also a place where the compiler has a problem: in
mul-by-abigits-per-word -- I'm tracking that down.
∂27-Jun-85 0802 JK
∂26-Jun-85 2318 ROD unwind-protect/catch/progv fix
Here is a fix which has certain virtues, the main one being it replaces
a current error message by some code. That means it can break nothing
that already worked.
In the longer term I think it is not the ``correct'' fix. If you thought
analyze-primop was bad then don't look at coerce-loc-and-rep (it started
out as a 20 line function, honest). It needs to be completely rewritten
and de-68000-ized. For this particular bug I think label-destinations
and the code generators for the three forms need to be upgraded.
In general I think label-destinations is currently a source of
much inefficincy in generating uselss multiple value code for
the three special forms in question. So probably I should tackle
all three of these in the cleanup task that's on my list. However,
big test files would be really helpful. I don't expect the task to
be either quick or painless.
Anyway here's the fix. In code-coerce.lisp in function coerce-loc-and-rep
find again the generator of the error message (its right after
a cond clause (eq 'stacked novals) and is followed by a bunch
of commented code. Remove the error mesage line and the comments
from the following code. Then make the following two changes:
In:
(emit deflap
`(move (frame ,stackh) mtempreg)
change to:
(emit deflap
`(move (frame ,(1+& stackh)) mtempreg)
then after:
(emit deflap label)
insert the following lines:
;; this must have come from catch/progv/unwind-protect
(emit deflap
`(adjust-stack ,(%anode-stack node))
Take an asprin and call me in the morning if you still have problems.
∂26-Jun-85 2337 ROD ps
That last line of code should have closed with ))), closing the (emit.
∂30-Jun-85 0940 JK
∂30-Jun-85 0845 ROD tape
No tape showed up so I assume you didn't send one. To avoid vthe introduction
of version skew I'm working on the following things this weekend (won't
finish them all, or probably any):
o Documneting the ``virtual machine'' specified in lap-library-68k so
that new versions can easily be written for new architectures.
o Writing a new code-coerce that is cleaned up and documented, and contains
the necessary hooks and extensibility for pdlnums etc., besides getting
rid of 68k dependencies (most of the code generators 68k dependencies are
in this file).
o Redoing the primop stuff so that more general register class specifications
can be done (e.g. (not areg)) and so that primop's can return multiple
vaslues as per JLW and EB's requests.
Actually I probably won't even get to start the third item this weekend.
---------------
Right --- things are a bit chaotic around here.
I would like to send another tape some time in the middle of next week.
I have modified defforms somewhat.
EB fixed a bug involving folding of constants in multiple value situations.
Another item for your list:
One needs to do the same kind of type dispatching in anal-primop
as in anal-procall. For example, + would like to turn to +& and it is
a primop. This points out a general difficulty in the current setup:
If it were possible to get at the list of subnodes (new slot in %anode?)
one could pull the silly type dispatch stuff from anal-procall
and do it more top level for both anal-procall and anal-primop
instead of decorating the body of analyze-primop with yet more code.
JK
∂07-Jul-85 1232 JK
To: ROD@SU-AI.ARPA, FTL@SU-AI.ARPA
Here's the other bug:
(defun foo (mnode1 mnode2 uvars constr alst)
(let ((lst1 (bxvars-of mnode1)) (lst2 (bxvars-of mnode2)))
(foo (bxmnode-of mnode1)
(bxmnode-of mnode2)
uvars
constr
(nconc (pairup lst1 lst2) alst) )))
this causes the generation of dotted lists thru analyze-extract-all-variable-refs
; loser is the end of the list. On the SUN this may never be
noticed since our memq (which was the function that blew up)
ignores the end of dotted lists.
proposed fix: as the first cond clause in the analyze ----- function have:
((eq refs 'loser) 'loser)
JK
P.S. the other bug seems to happend whenever a primop applies to
a special.
By the way, EKL now runs in LCL
>
∂15-Jul-85 0746 JK flavors
∂12-Jul-85 1250 FAHLMAN@CMU-CS-C.ARPA flavors
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Jul 85 12:50:25 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 12 Jul 85 15:50:57-EDT
Date: Fri, 12 Jul 1985 15:50 EDT
Message-ID: <FAHLMAN.12126473946.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Jussi Ketonen <JK@SU-AI.ARPA>
Subject: flavors
In-reply-to: Msg of 12 Jul 1985 13:30-EDT from Jussi Ketonen <JK at SU-AI.ARPA>
Jussi,
We've got mail crossing every whichway, since RPG answered my note to
you and I sent a reply to him. I'll send you a copy of that.
Basically, Dick asked what I thought was fair with respect to Skef
Wholey and Rob Maclachlan, and I proposed something. I don't know if it
will run afoul of the various constraints on stock. I hope you folks
have not painted yourselves into a corner where stock can only be
offered to people who are working for you full-time.
Thanks for the invitation to visit Lucid. I'd like to do that sometime
soon, just to stay in touch with what's happening out there. However, I
will be spending two weeks in Austria starting July 20, and then about
the time I've recovered from that trip it's off to IJCAI for me and
presumably also for most of the Lucidites. For various reasons, I can't
really stretch the IJCAI trip. I super-quick trip could be scheduled in
between there sometime, but that probably wouldn't accomplish anything
that couldn't be done by phone or mail, so it looks like sometime in
September is our best bet. I'll probably see you folks at IJCAI, and we
can discuss it then.
As I told Dick, I think that both Rob Maclachlan and Skef Wholey would
be valuable to you as occasional consultants. Steve Handerson will be
leaving the Spice Lisp project in September (the money that was paying
for his slot has run out), so you could consider hiring him full-time,
but I'm not sure he'd make it in a tight-deadlines company like Lucid.
Steve occasionally has a good month and has written some very nice
chunks of code for us, but then he'll have a month or two when he
doesn't do anything at all except play games and walk around looking
stoned. He's just not very reliable. It may be that with some
different kind of management Steve would turn into a winner, but he just
doesn't seem to thrive under the loose structure of the Spice Lisp
group, and he says he doesn't want to work under any tighter control.
-- Scott
∂16-Jul-85 1303 F.DUFFIE@SU-GSB-WHY.ARPA Re: TeX index macros
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 16 Jul 85 13:03:07 PDT
Date: Tue 16 Jul 85 13:01:47-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: Re: TeX index macros
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Tue 16 Jul 85 11:34:00-PDT
For you, Virginia, any time is fine. How about tomorrow other than
10-12:30. If you want to meet for lunch, say 1:15 PM at the faculty club?
Would you let me know? My number here is 497-1976. You can leave a
message if I'm not in. IMSSS is keeping me out of the office a lot.
I have some new reading recommendations.
tovarich D.
-------
∂17-Jul-85 1639 F.DUFFIE@SU-GSB-WHY.ARPA TeXmacros to Virginia Kean
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 17 Jul 85 16:39:35 PDT
Date: Wed 17 Jul 85 16:38:11-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: TeXmacros to Virginia Kean
To: ftl@SU-AI.ARPA
OK Virginia; I got this to work. (My pride was at stake!)
Just put
\input kean.tex
at the beginning of your file. Then ↑{object} sends objext to index.tex
and ~{object} sends object to gloss.tex.
I presume ↑↑{ } and ~~{ } are the silent versions.
I'll attach kean.tex to this memo. Thanks for dropping over today. You are
always welcome.
Darrell
\def\up{↑}
\newwrite\inx %setup for indexing TeXbook, pp 423 - 424
\immediate\openout\inx=index % file for index entries
\newif\ifsilent
\def\specialhat{\ifmmode\def\next{↑}\else\let\next=\beginxref\fi\next}
\def\beginxref{\futurelet\next\beginxrefswitch}
\def\beginxrefswitch{\ifx\next\specialhat\let\next=\silentxref
\else\silentfalse\let\next=\xref\fi \next}
\catcode`\↑=\active \let ↑=\specialhat
\def\silentxref↑{\silenttrue\xref}
\chardef\bslash=`\\% \bslash makes a backslash
\def\xref{\futurelet\next\xrefswitch} % branch on the next character
\def\xrefswitch{\begingroup\ifx\next|\aftergroup\vxref
\else\ifx\next\<\aftergroup\anglexref
\else\aftergroup\normalxref \fi\fi \endgroup}
\def\vxref|{ }
\def\anglexref\<#1>{ }
\def\normalxref#1{\def\xreftype{0}\def\text{#1}\let\next=\text\makexref}
\newif\ifproofmode
\proofmodetrue % false at final stage
\def\makexref{\ifproofmode
\xdef\writeit{\write\inx{\text,\space\space\noexpand\number\pageno}}\writeit
\else\ifhmode\kern0pt \fi\fi
\ifsilent\ignorespaces\else\next\fi}
\newwrite\gls %setup for glossary: TeXbook, pp 423 - 424
\immediate\openout\gls=gloss % file for index entries
\newif\ifsilent
\def\specialtilde{\ifmmode\def\gnext{~}\else\let\gnext=\begglsref\fi\gnext}
\def\begglsref{\futurelet\gnext\begglsrefswitch}
\def\begglsrefswitch{\ifx\gnext\specialtilde\let\gnext=\silentgxref
\else\silentfalse\let\gnext=\gxref\fi \gnext}
\catcode`\~=\active \let ~=\specialtilde
\def\silentgxref~{\silenttrue\gxref}
\chardef\bslash=`\\% \bslash makes a backslash
\def\gxref{\futurelet\gnext\gxrefswitch} % branch on the next character
\def\gxrefswitch{\begingroup\ifx\gnext|\aftergroup\vgxref
\else\ifx\gnext\<\aftergroup\anglegxref
\else\aftergroup\normalgxref \fi\fi \endgroup}
\def\vgxref|{ }
\def\anglegxref\<#1>{ }
\def\normalgxref#1{\def\gxreftype{0}\def\gtext{#1}\let\gnext=\gtext\makegxref}
\newif\ifproofmode
\proofmodetrue % false at final stage
\def\makegxref{\ifproofmode
\xdef\writeit{\write\gls{\gtext,\space\space\noexpand\number\pageno}}\writeit
\else\ifhmode\kern0pt \fi\fi
\ifsilent\ignorespaces\else\gnext\fi}
-------
∂17-Jul-85 1754 F.DUFFIE@SU-GSB-WHY.ARPA Re: index macros
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 17 Jul 85 17:53:58 PDT
Date: Wed 17 Jul 85 17:52:33-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: Re: index macros
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Wed 17 Jul 85 17:43:00-PDT
A great pleasure.
d
-------
∂25-Jul-85 0849 F.DUFFIE@SU-GSB-WHY.ARPA doublecolumns macro
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 25 Jul 85 08:49:44 PDT
Date: Thu 25 Jul 85 08:48:48-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: doublecolumns macro
To: ftl@SU-AI.ARPA
What a subject for a memo! Good morning. I enclose the
doublecolumns macro and associated nonsense in the file col.tex, and
a sample input in the file sample.tex. My sample has specified an
eight point font; this is of course up to you and the fonts supported
at your facility. You do not need the other input files that I'm
using. Also note that with my version, as oppposed to the one you gave
me, you do not need to end a line of input with a period. A standard
index does not have periods in this fashion. You must, however, begin
and end the index entries as I have. In particular, don't forget
the }\endgroup at the end. You may want to play with spacing. Your
columns macro conveniently splits up a page properly even with
non standard \hsize and \vsize (I think).
Let me know if col.tex misbehaves.
Again, thanks for your help with this. Between the two of us, we're
making progress!
The Hers column in this morning's NYT is interesting.
Have a marvelous day.
Warm regards. Darrell
-------
∂25-Jul-85 0851 F.DUFFIE@SU-GSB-WHY.ARPA the files
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 25 Jul 85 08:50:51 PDT
Date: Thu 25 Jul 85 08:49:57-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: the files
To: ftl@SU-AI.ARPA
\newdimen\fullhsize
\fullhsize=\hsize
\newdimen\fullvsize
\fullvsize=\vsize
\catcode`@=11
\newbox\partialpage
\def\begindoublecolumns{\begingroup
\output={\global\setbox\partialpage=\vbox{\unvbox255\bigskip}}\eject
\output={\doublecolumnout} \hsize=14pc \vsize=89pc}
\def\enddoublecolumns{\output={\balancecolumns}\eject
\endgroup \pagegoal=\vsize}
\def\doublecolumnout{\splittopskip=\topskip \splitmaxdepth=\maxdepth
\overfullrule=0pt
\dimen@=44pc \advance\dimen@ by-\ht\partialpage
\setbox0=\vsplit255 to\dimen@ \setbox2=\vsplit255 to\dimen@
\onepageout\pagesofar
\unvbox255 \penalty\outputpenalty}
\def\pagesofar{\unvbox\partialpage
\wd0=\hsize \wd2=\hsize \hbox to\fullhsize{\box0\hfil\box2}}
\def\balancecolumns{\setbox0=\vbox{\unvbox255} \dimen@=\ht0
\advance\dimen@ by\topskip \advance\dimen@ by-\baselineskip
\divide\dimen@ by2 \splittopskip=\topskip
{\vbadness=10000 \loop \global\setbox3=\copy0
\global\setbox1=\vsplit3 to\dimen@
\ifdim\ht3>\dimen@ \global\advance\dimen@ by1pt \repeat}
\setbox0=\vbox to\dimen@{\unvbox1}
\setbox2=\vbox to\dimen@{\unvbox3}
\pagesofar}
\def\onepageout#1{\ifodd\pageno{\global\headline={\hbox to \fullhsize{
\rm\hfil\folio}}}
\else{\global\headline={\hbox to \fullhsize{\rm\folio\hfil}}}\fi
\shipout\vbox{\offinterlineskip\vbox{\makeheadline}#1\makefootline}
\advancepageno
\ifnum\outputpenalty>-\@MM \else\dosupereject\fi}
\pageno=193
\centerline{\ti INDEX}
\bigskip
\font\eightrm=cmr8
\eightrm
\input thesis.def
\twosided
\newdimen\sqht \sqht=2.4pt % \square
\input col.tex
\begindoublecolumns
\baselineskip=9.9pt
\parskip=0pt plus 0.8pt
\begingroup \let\par=\cr \obeylines %
\halign{#\hfil
a.e., 22
a.s., 22
Aase, 158
Janich, 8
Kallianpur, 134
Karatzas, 158
Kennedy, 158
Klein, 112
random variable, 20
rank, 59
RCLL, 74
real security, 62
recession cone, 6
Reed, 33
refinement, 45
Revuz, 111
reward, 103
Riemann, 85
right--continuous filtration, 75
right--continuous, 74
right--limits, 74
Rishel, 144
risk tolerance, 166
Robertson, 8
root node, 54
Ross, 24,112,177
Royden, 33,85
Rudin, 24,49
Saddle Point Theorem, 41
saddle point, 41
Samuelson, 158
Savage model of beliefs and preferences, 25
Savage, 25
scalar multiplication, 2
scalar, 2
Schaefer, 8,33
Scholes, 90
Schal, 112
security price process, 115
security set, 33
security, 33,55,86
segment, 10
selector, 109
self, 5
self--financing, 91
semimartingale, 77
separable, 9
separated by a hyperplane, 18
Separating Hyperplane Theorem, 15
Sethi, 158
Shafer, 11,19,64
shareholder value, 66
Shiryayev, 134
Shreve, 112,158
sigma--algebra, 20
signum, 150
Simon, 33
simple process, 81
simple random variable, 22
single agent Markov equilibrium, 116
single--beta asset pricing model, 164
single--beta model, 165
Skorohod, 74
slack, 57,134
slack, 92
Sonnenschein, 19
span, 33
spanning number, 89
spanning, 87
spot price process, 54,85
square--integrable, 79
Standard Brownian Motion, 76
standard deviation of the market rate of return, 164
state process, 102,159
state space, 102
state--independent preferences, 25
state--independent, 25
stationary feedback control, 107
stationary infinite horizon discounted control problem, 104
stationary Markov control problem, 107
stationary reward, 106
stationary, 40
Stieltjes integral, 23
Stieltjes, 85
Stiglitz, 39,71
stochastic differential equation, 128
stochastic differential, 127
stochastic economy, 86
stochastic growth Markov control problem, 119
stochastic growth model, 118
stochastic integral, 79
stochastic process, 72
stock market equilibrium, 36
stopping time, 76
strict contraction, 109
strict order, 8
strict preference relation, 11
strictly convex, 10
strictly monotonic preference relation, 9
strictly positive continuous linear functional, 48
strictly price supported allocation, 12
strong continuous, 110
strongly convex, 10
Stroock, 134
sub--tribe, 45
Suchanecki, 49
sum of sets, 6
superdifferentiable, 43
supergradient, 43
support of the distribution, 27
symmetric difference, 49
Teicher, 24
term structure of interest rates, 172
terminal node, 54
the usual conditions, 75
Thompson, 112
tight, 92
time set, 71
Ting, 49
topological dual, 5
topological space, 6
topological vector spaces, 4
topology, 4
total consumption set, 16
total production set, 15
trace, 127
trading strategy, 115
trading strategy, 56
trading strategy, 86
transition function, 106
transitive, 8
tribe generated, 21
tribe, 20
trivial tribe, 46,78
upper hemicontinuous, 105
upper semicontinuous correspondence, 105
upper semicontinuous, 105
utility function, 8
utility represention, 9
Vakhania, 49
value function, 100,107,138
value of the control problem, 103
value operators, 108
Van Vleck, 112
Varadhan, 134
variance, 31
vector space, 2
vector subspace, 32
version, 22,79
von Neumann, 19
von Neumann--Morgenstern, 25
Wald, 112
Wald, 19
Walras, 19
Walrasian equilibrium, 13
weakly dominates, 14
weakly efficient allocation, 14
wealth process, 148,160
Werner, 63
Williams, 78,85,134
Wilson, 39
Yannelis, 19,52,90
Yip, 49
Yushkevich, 112
Zame, 19,52,90
zero, 2
}\endgroup
-------
∂26-Jul-85 1025 F.DUFFIE@SU-GSB-WHY.ARPA Re: index
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 10:25:20 PDT
Date: Fri 26 Jul 85 10:24:21-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: Re: index
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Fri 26 Jul 85 09:47:00-PDT
There's seems to be a big lag between sending and receiving. If you ever
need help in a hurry, perhaps you should call.
I can't really think of anything useful to say about the problems you're
having with doublecolumns. It works OK here. On the lines that are
too long for half a pagewidth, I had hoped that the macro would automatically
move to a new line and indent; it appears that it does not. Thus I will
be doing a little bit of manual adjustment before my last version. This
is a minor problem, for me at least.
Good luck with your extra work this weekend. I will be hibernating with my
own. There is so little time before I'm gone. I shall miss our
discussions.
Again, thanks.
Darrell
-------
∂26-Jul-85 1111 SCHERLIS@CMU-CS-C.ARPA Re: Lucid manual
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 11:11:40 PDT
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Fri 26 Jul 85 14:12:35-EDT
Date: Fri 26 Jul 85 14:12:30-EDT
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: Re: Lucid manual
To: FTL@SU-AI.ARPA
In-Reply-To: Message from "Lucid <FTL@SU-AI.ARPA>" of Fri 26 Jul 85 10:53:00-EDT
Virginia --
Thanks for your note. I'll send a sketch of a sample session in
the next few days. I'll also send along the usual collection of nits
picked from the present edition.
Do you know if Steele has an errata list for the CLM (and a new
index!) that we could distribute with our documentation? That, together
with our document, would make our software worth purchasing for the
documentation alone.
Bill
-------
∂02-Aug-85 0702 SCHERLIS@CMU-CS-C.ARPA documentation notes
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Aug 85 07:02:42 PDT
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Fri 2 Aug 85 10:04:43-EDT
Date: Fri 2 Aug 85 10:04:42-EDT
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: documentation notes
To: ftl@SU-AI.ARPA
Virginia --
I must apologize, but events here have prevented me from getting
my comments off to you on time. I will send them in the next 24 hours.
Sorry again,
Bill
-------
∂03-Aug-85 1538 SCHERLIS@CMU-CS-C.ARPA First installment of COMMENTS
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Aug 85 15:38:44 PDT
Received: ID <SCHERLIS@CMU-CS-C.ARPA>; Sat 3 Aug 85 18:40:46-EDT
Date: Sat 3 Aug 85 18:40:44-EDT
From: Bill.Scherlis@CMU-CS-C.ARPA
Subject: First installment of COMMENTS
To: ftl@SU-AI.ARPA
Virginia --
Here is the first installment (of several, it seems) of comments
on the reference guide. I'm making all comments that come to mind,
including some that won't deserve our attention for a while. Let
me know if this is useful -- and how it can be made more useful.
Bill
===========================
Lucid Portable Common Lisp -- Suggestions and Comments (wls)
Overall, I am quite impressed with the Concise Reference Guide. It
contains the information that users will most likely need to reference
regularly while programming. It is organized well, and it enhances the
Steele book by providing some essential clarifying information. The
quality of the writing is generally quite good.
I have a number of comments, however, concerning overall structure,
style, and the contents of the individual chapters. I will try to
distinguish suggestions for long-term improvement from changes that are
more urgent.
I. Requirements.
The Reference Guide should contain at least the following:
-- An enumeration of all the Common Lisp entities (e.g., functions,
constants, macros) together with essential information (argument format and
types, result format and types).
-- Documentation for all Lucid additions to the Common Lisp language.
-- Clarifications of contradictory or confusing sections of the Steele
manual.
-- An indication of the extent to which optional language features (with
respect to the Steele manual) are implemented (for example, character set
and font information).
-- Language summary information (concerning format, readtable
initialization, types, and so on).
-- Documentation for the Lucid supporting environment common to all Lucid
development systems.
-- Documentation for system-specific features (for Sun, Apollo, etc).
The Guide should be organized in a way such that:
-- Readers are easily able to find the information they need.
-- Readers who are familiar with the language can use the Reference Guide
in their daily work and, generally, leave the Steele book on the shelf.
-- Lucid-specific features are always distinguished from features required
by the Steele manual.
-- New users who are familiar with Common Lisp but new to Lucid
implementations can acclimatize quickly.
-- Users who have used a different Lucid Common Lisp implementation can
move easily to the one described.
!
II. Comments on Structure and Style
(1) I like the idea of numbering chapters consistently with the Steele
book. But the large number of appendices forced by that structure is
ackward. Also, the material in Chapter 1 applied to the entire manual --
not just to the ensuing chapters. We discussed this and considered a
hierarchical numbering scheme. I'm still in favor of such a scheme.
Perhaps we should have:
Book A: Introduction:
The present Preface, Chapter 1. The new Scenario.
Book B: The Lucid Language Environment:
The present Appendices C -- H.
Book B: Common Lisp Language Guide:
The present Chapters 2 -- 25.
Book C: The exhaustive lists of notions.
Appendices A, B. A new full index.
But I'm not very strongly committed to this order.
(2) All Lucid functions (and other notions) should be flagged as such, at
EVERY instance of mention. This will help readers (and glancers-through)
from thinking that we are somehow twisting the language (and the appelation
"Common Lisp") in the same way some other groups have. I suggest a special
mark (the spade is fine) that appears each time the name is mentioned, but
in a nonobtrusive way. Use of a special mark (as a superscript, say) will
prevent readers from thinking the mark is part of the function name.
(3) Lucid notion names, when they appear, should be cross-referenced to the
point of their definition (unless it is in the same chapter). Otherwise,
readers cannot find all relevent descriptive prose. An entry in the
listing presently in Appendix B should contain pointers to all chapters
where the notion is discussed or elaborated.
(4) The prosy structure of the individual chapters is fine if they are
short (as are most of them), but for the longer chapters (e.g.,
input/output, file-system) a mini-table of contents (without page
references: just a list of topics) at the start of the chapter would be a
help. Also, placing topic phrases at the start of certain paragraphs
(in italics, say) would be a great help for readers who are scanning
through trying to find some bit of information.
(5) There is some question about how to make an index for the book.
Appendix A in its present form would overlap considerably with an index.
Although it is a difficult task, I would suggest that we ultimately make a
single overall index that included all CommonLisp notions, all Lucid
extensions, all keywords in use, and all lambda-list items (i.e.,
&optional, etc). The information presently included in Appendix A would be
included, along with references to the chapters in which notions are
defined. Including the parameter lists is essential! (Presently, a reader
interested in, say, ECASE would, after looking in Appendix A, need to
look in the index of the Steele book in order to determine which chapter of
OUR manual contains our prose, if any, discussing Evalhook and related
Lucid extensions.)
(6) There is also some question about where to document the Lucid
extensions. Either we can keep all the documentation in one place (the
present Appendix B) or we can distribute the definitions into the chapters.
My feeling at the moment is to keep the present structure, but to add some
detail to the discussions in the chapters. (This is generally the case;
the point here is to recognize the issue.)
(7) Style. I like the style. My only comment is to avoid starting
sentences with symbols (e.g., para 4, p.8).
!
III. A Scenario.
The present Preface contains a very brief example of interaction with the
system. For users new to our system (but generally familiar with Lisp), it
would be useful to have an example protocol of interaction with the system.
This provides a single place where users and, more importantly, potential
users, can look to get an idea of how errors are handled and how the
debugging features can be used.
I suggest here the ingredients of a sample protocol. Someone with access
to a Lucid system should sit with DRIBBLE and make one up.
-- Start the Lisp.
-- Show the Lisp banner.
-- Evaluate a simple form.
-- Produce an error from a top-level evaluation and type :A to abort.
-- Enter a recursive function definition containing an error.
-- Evaluate a call, causing an error, and type :C to continue.
-- Use TRACE.
-- Use DRIBBLE.
!
IV. Comments on the Chapters.
Detailed comments are given below. I have marked the comments that (I
believe) require immediate attention with "**".
Chapter 1.
-- "Lisp, Second Edition" by W and H --> "Lisp" by W and H (second edition)
-- In the syntactic descriptions for functions, put more space between the
function name and the argument list.
** p.1, Para 1: mention Lucid functions and the spade notation.
-- p.1, Para 3, last line: or -> and.
-- p.1, Para 6: say that programs can be in mixed case as well.
-- example 4: explain the arg syntax for SAMPLE-SPECIAL-FORM in words or by
example (after the description of the meta-syntax). E.g.,
(SAMPLE-SPECIAL-FORM foo (x y z) bar (baz))
Actually, it is not clear how
(SAMPLE-SPECIAL-FORM nil nil)
will be parsed!
** Brackets appear in both italics and in typewriter font. (See, for
example, the lambda-list syntax in Ch.5.)
** The italic words in the syntactic descriptions cannot always be
construed as parameter NAMES (e.g., in the case of {var}*).
Chapter 2.
** Several important types are missing: SEQUENCE, COMMON, BIT, FUNCTION,
and possibly others. But I really like the idea of a type diagram.
-- Include pointers to Chapters 4 and 9.
Chapter 3.
-- In the "indefinite scope" paragraph: What is meant by "in any program"?
** In the "dynamic extent: paragraphs, add "in time" at the ed of the first
sentence.
-- Here are examples of the four binding phenomena mentioned:
- Lexical scope: (non-special) parameters, labels, block names.
- Indefinite scope: top level names, such as function and macro names.
- Dynamic extent: objects referenced by identifiers declared special.
- Indefinite extent: cons cells, closures, and other heap objects.
** It might be a good idea to include the list at the bottom of p.39 of the
Steele book.
Chapter 4.
** In sentence 3, "other types of objects" is a bit confusing.
-- In the TYPESPEC syntax: Explain the parameterization in NUMBER-limit.
Perhaps use some other font for the type parameters in the TYPESPEC
production. Also, say somewhere that the first limit is a low limit and the
second is a high limit. Are the limits optional (and, in particular, is
the second limit really optional)?
** After &optional in ARG-TYPESPEC-LIST should be one or more TYPESPECs.
-- (The brackets are in different fonts.)
Chapter 5.
** In sentence 2, results are ZERO or more values.
-- In para 2, change "functional computation" to "evaluation of a function".
Chapter 6.
-- Add a paragraph summarizing the differences between EQ, EQL, EQUAL, and
EQUALP.
Chapter 7.
** Define "generalized variable." (This concept is unfamiliar to old-world
Lispers, and a quick definition or example would help here.)
-- Would it be better to move the discussion of PLACEs before the full
enumeration of notions?
Chapter 8.
-- Is this the place (if any) to mention caching (if any) of macro
expansions? Should DECACHE-EVAL be mentioned here? (I don't know.)
-------
∂07-Aug-85 0848 F.DUFFIE@SU-GSB-WHY.ARPA Fonts to Virginia Kean
Received: from SU-GSB-WHY.ARPA by SU-AI.ARPA with TCP; 7 Aug 85 08:47:56 PDT
Date: Wed 7 Aug 85 08:43:18-PDT
From: James Duffie <F.DUFFIE@SU-GSB-WHY.ARPA>
Subject: Fonts to Virginia Kean
To: FTL@SU-AI.ARPA
Virginia,
Attached to this memo is a file that sets up a ninepoint font suitable for
an index. You automatically get roman, slant, italics, boldface, and mathmode
with appropriately sized super and super-super scripting automatically
after the line
\ninepoint
Of course, you must have the line
\input fonts
at the front of your file. If you don't want ninpoint forever, you can
group:
{\ninepoint Now I'm in ninepoint.} Now I'm not.
Or you can switch back and forth as indicated by the more general
package of fonts in the TeXBOOK, page 414.
Remember that some of the fonts called for may not be preloaded on your
system. They aren't at GSB. They are at SCORE. See the TeXBOOK for
preloading instructions. It's easy; see the TeXBOOK, page 350. For
example, to preload cmr9 (ninepoint computer modern roman) simply
write
\font\preloaded=cmr9
Note that some fonts I've called for may not even be available on your
system. In that case there ought to be a close substitute.
OK Here comes my little fonts.tex . Let me know if you need more help.
Regards, Darrell
%This package of fonts set up by Darrell Duffie
%No liability for errors. It works for me, except for the
%comma and colon in ninepoint math mode, which I hope to fix later.
%
%Depending on your system, some of the fonts below have to be preloaded.
%See the TeXBook for details.
%The above is my excuse for `documentation'.
%
\font\ninerm=cmr9 \font\eightrm=cmr8 \font\sixrm=cmr6
\font\ninei=cmi9 \font\sixi=cmi6
\font\ninesy=cmsy9 \font\sixsy=cmsy6
\font\ninebf=cmb9
\font\nineit=cmi9
\font\ninesl=cms9
\font\fiverm=cmr5
\font\fivei=cmi5
\font\fivesy=cmsy5
\def\ninepoint{\def\rm{\fam0\ninerm}%switch to ninepoint (TeXBOOK,
% p.414) missing some features
\textfont0=\ninerm \scriptfont0=\sixrm \scriptscriptfont0=\fiverm
\textfont1=\ninei \scriptfont1=\sixi \scriptscriptfont1=\fivei
\textfont2=\ninesy \scriptfont2=\sixsy \scriptscriptfont2=\fivesy
\textfont\itfam=\nineit \def\it{\fam\itfam\nineit}
\textfont\slfam\ninesl \def\sl{\fam\slfam\ninesl}
\textfont\bffam\ninebf \def\bf{\fam\bffam\ninebf}
\normalbaselineskip=11pt
\setbox\strutbox=\hbox{\vrule height8pt depth3pt width0pt}
\normalbaselines\rm}
-------
∂24-Oct-86 1619 edsel!bhopal!lgd@navajo.stanford.edu concepts.tex
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Oct 86 16:19:05 PDT
Received: by navajo.stanford.edu; Fri, 24 Oct 86 16:17:19 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01958; Wed, 22 Oct 86 18:35:13 pdt
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA11641; Wed, 22 Oct 86 18:34:24 PDT
Date: Wed, 22 Oct 86 18:34:24 PDT
From: edsel!bhopal!lgd@navajo.stanford.edu (Linda G. DeMichiel)
Message-Id: <8610230134.AA11641@bhopal.edsel.uucp>
To: navajo!ftl%sail.stanford.edu@navajo.stanford.edu
Subject: concepts.tex
\input macros
\def\bookline{\CLOS\ Specification}
\def\chapline{Basic User Interface Concepts}
\beginChapter 1.{Common Lisp Object System Specification}%
{Basic User Interface Concepts}{Basic User Interface Concepts}
Contributors to this document include Daniel G. Bobrow, Linda G.
DeMichiel,\break Richard P. Gabriel, Kenneth Kahn, Sonya E. Keene,
Gregor Kiczales, Larry\break Masinter, David A. Moon, Mark Stefik, and
Daniel L. Weinreb.
Comments and suggestions on this document are encouraged.
Changes will be incorporated over the next several months.
This text will be made available to the X3J13 Committee for the
Common Lisp Standards effort.
\endTitlePage
\beginSection{Introduction}
This proposal presents a description of the standard user
interface for object-oriented programming in the \CLOS. A second
document, ``The \CLOS\ Meta-Object Protocol'' describes how the
\CLOS\ can be customized to accommodate existing object-oriented
paradigms and to define new ones.
Under this proposal, the primitive entities of Common Lisp are called
{\bit objects}. The fundamental objects of the \CLOS\ are
classes, generic function objects, and method objects. [What is
the ontological status of method combination?] [Meta-objects?]
A {\bit class\/} object determines the structure and behavior of a set
of other objects, called its {\bit instances}. The class of an object
indirectly determines the set of operations into which the object can
enter. It is an important feature of the \OS\ that every Common Lisp
data structure is an object that is an {\bit instance\/} of a unique
class.
{\bit Generic functions} are objects that may be specialized to
provide class-specific operations. A generic function is a function
that is able to designate one of a set of possible operations based on
the classes of its arguments. A generic function can be used as an
argument to {\bf funcall} and {\bf apply} and stored in the
symbol-function cell of a symbol.
The class-specific operations provided by generic functions are
themselves defined and implemented by {\bit methods}. A method is
also a function object. The method object contains a method function
and a set of {\bit argument specializers\/} that specify when the
given method is applicable.
% A method can be used as an argument to
% {\bf funcall} and {\bf apply} and stored in the symbol-function cell
% of a symbol. [This needs to be decided.]
When a generic function is invoked, the selection and sequencing of
the individual methods that are applicable may be further controlled by the
{\bit method combination\/} facility. Method combination qualifiers,
types, and rules [or what do we call these?] can be used to precisely
define which methods are invoked when a given generic function is called
with specific classes of arguments.
\vfill
\endSection%{Introduction}
\beginSection{Classes}
A {\bit class\/} is an object that determines the structure and behavior
of a set of other objects, called its {\bit instances}.
Like other objects, all classes are themselves instances of other classes.
The class of the class of an object is termed the {\bit metaclass\/} of that
object. Less formally, we will also use the term {\bit metaclass\/} to
refer to a class that has instances that are themselves classes.
The metaclass determines the form of inheritance used by its classes and
the representation of the instances of those classes.
A class can inherit properties directly or indirectly from one or more
other classes. A class that is defined so as to inherit from another
class is said to {\bit include\/} that class. A class that inherits
from a class is said to be a {\bit subclass\/} of that inherited
class. A class from which another class inherits properties is called
a {\bit superclass\/} of the inheriting class. The inheritance
relationship is transitive.
Classes are organized into a {\bit lattice}. There is a mapping from
the Common Lisp type lattice into the Common Lisp Object System class
lattice. All of the standard Common Lisp types specified in
{\it Common Lisp: The Language\/} by Guy L. Steele Jr. except {\bf atom}
and {\bf common} have a corresponding class.
The \OS\ includes a set of standard objects. We use the term
{\bit standard object\/} to refer to any object whose metaclass is
{\bf class}. The class {\bf object} specifies the default behavior of the
set of all objects whose metaclass is {\bf class}. In other words,
all standard objects inherit (directly or indirectly) from the class
{\bf object}.
The \OS\ also defines a set of standard classes. A {\bit standard
class\/} is any class that is an instance of the class {\bf class}.
The class {\bf class} is itself of class {\bf class}. It is therefore
both a standard class and a standard object. The class {\bf object}
is also a standard class since it is also an instance of the class
{\bf class}. As a standard object, the class {\bf class} is a
subclass of the class {\bf object}.
\vfill\eject
\Vskip 1pc!
\boxfig
{\bf\tabskip 0pt plus 1fil
\halign to \hsize{&#\hfil\cr
array&hashtable&sequence\cr
atom*&integer&short-float\cr
bignum&keyword&simple-array\cr
bit&list&simple-bit-vector\cr
bit-vector&long-float&simple-string\cr
character&nil&simple-vector\cr
common*&null&single-float\cr
compiled-function&number&standard-char\cr
complex&package&stream\cr
cons&pathname&string\cr
double-float&random-state&string-char\cr
fixnum&ratio&symbol\cr
float&rational&t\cr
function&readtable&vector\cr
}}
\caption{Standard Common Lisp types. All these types except atom and common have\break
a corresponding class.}
\endfig
\beginsubSection{Defining Classes}
Classes with metaclass {\bf class} (standard classes)
are defined with the macro {\bf defclass}.
The use and definition of classes with other metaclasses %are
will be
discussed in the chapter ``Meta-Object Protocol.''
The syntax for {\bf defclass} is given in Figure~1-3.
The new class created by {\bf defclass} is a subclass of all the
classes specified in the {\it includes\/} list of the {\bf defclass}
form. A class that is defined in this way is the most specific
element of a sublattice from which descriptions are inherited. The
order of the classes in the {\it includes\/} list determines a local
precedence for classes and for the selection of methods. The
transitive closure of all the {\it includes\/} specifies all the
classes that this class inherits from. An ordering of this list for
purposes of precedence is called the {\bit class precedence list}.
The class precedence list for a standard class is computed as follows:
[To be spec'd.]
%1. A list is created, starting with the given class, of all the classes
%encountered in a depth-first traversal of
%the classes in the {\it includes\/} list of that class. The classes in
%the {\it includes\/} list are processed in left-to-right order (the order
%of local precedence).
%
%2. If more than one occurrence of a class appears in the list that
%results from step 1, only the last occurrence of that class is kept.
%
%3. It is verified that the list that results from step 2 preserves the
%local precedence indicated in the {\it includes\/} list of each class
%encountered. If any such local precedence is violated, an error is
%signalled.
\endsubSection
\beginsubSection{The Structure of Class Objects}
\endsubSection%{The Structure of Class Objects}
\beginsubSection{Creating Instances of Classes}
\endsubSection%{Creating Instances of Classes}
\beginsubSection{Superclasses}
\endsubSection%{Superclasses}
\beginsubSection{Inheritance}
\endsubSection%{Inheritance}
\beginsubSection{Class Precedence}
%brief introduction to notion of class precedence
\endsubSection%{Class Precedence}
\beginsubSection{Accessing Slots}
Slots can be accessed in two ways: by use of the accessors defined in
the {\bf defclass} form and by use of the primitive function
{\bf slot-value}.
The function {\bf slot-value} can be used with any of the slot names
specified in the {\bf defclass} form to access a specific slot in an object
of the given class. If the object has no such slot, an error is
signalled.
The automatically-generated accessors specified in the {\bf defclass} form
are implemented in terms of {\bf slot-value}.
\endsubSection
\beginsubSection{Types and Classes}
The \OS\ maps the Common Lisp type space into the space
of classes.
Figure~1-2 displays part of the lattice of classes that are instances of
a subclass of {\bf standard-type-class}.
Creating a type by means of {\bf defstruct} also creates a class in
this lattice. Such a class is an instance of {\bf structure-class}
and an immediate subclass of the class that
corresponds to the type given as its
{\bf :includes} argument. If no such type was specified, it
is an immediate subclass of the class {\bf t}.
The following precedence relations hold among classes:
{\bf list} has precedence over {\bf symbol} (for {\bf nil});
{\bf array} has precedence over {\bf sequence} (for vectors);
{\bf vector} has precedence over {\bf simple-array} (for simple-vectors);
{\bf bit-vector} has precedence over {\bf simple-array} (for simple-bit-vectors);
and {\bf string} has precedence over {\bf simple-array} (for simple-strings).
The classes {\bf number}, {\bf integer}, {\bf rational}, {\bf float},
{\bf list}, and {\bf sequence} are {\bit abstract classes}, that is,
they can never be directly instantiated. The function {\bf class-of}
will never return one of these classes.
\endsubSection%{Integrating Types and Classes}
\eject
\beginsubSection{Lattice of classes that are instances of standard-type-class}
\fig{
\def\IgnoreLineBreaks{\catcode'15=9 \catcode'12=9}
\def\IgnoreWhiteSpace{\catcode'11=9 \catcode'40=9 \IgnoreLineBreaks}
\def\DontIgnoreWhiteSpace{\catcode'12=\active\catcode'15=5\catcode'11=10\catcode'40=10}
\font \pipefont= circlew10
\font \foofont = amr10 at 1sp
\IgnoreWhiteSpace
\let \adv=\advance
\def\he{height}
\def\wi{width}
\def\de{depth}
\newdimen \stroke
\stroke= \fontdimen8\pipefont % thickness of line in circles
\newdimen \radius \radius=6pt % radius of circles
\newdimen\irad \irad=\radius\advance\irad by -.5\stroke
\newdimen\orad \orad=\radius\advance\irad by .5\stroke
\newbox\BStrutbox
\setbox\BStrutbox\hbox{\vrule\wi0pt\he8.5pt\de8.5pt}
\def\BoxStrut{\unhcopy\BStrutbox}
!% Arrows
\newdimen\ArrowShift
\ArrowShift=\fontdimen22\tensy
\advance\ArrowShift by -0.5\stroke
\def\StrikeOut #1
{ \setbox0\hbox{#1}
\hbox to 1\wd0
{ \vrule \he\stroke\de0pt\wi\wd0
\hskip-\wd0
\unhbox0
}
}
\def\LeftArrow
{ \hskip 0.5\stroke
\StrikeOut{\lower\ArrowShift\hbox to 10pt{\tensy\char'40\hss}}
}
\def\RightArrow
{ \StrikeOut{\lower\ArrowShift\hbox to 10pt{\hss\tensy\char'41}}
\hskip 0.5\stroke
}
\def\ArrowLine
{ \StrikeOut{\hskip 10pt\hskip 0.5\stroke}
}
\def\LeftToRight
{ \let\RightSideArrow=\ArrowLine
\let\LeftSideArrow=\RightArrow
}
\def\RightToLeft
{ \let\LeftSideArrow=\ArrowLine
\let\RightSideArrow=\LeftArrow
}
\def\NoArrows
{ \let\LeftSideArrow=\ArrowLine
\let\RightSideArrow=\ArrowLine
}
!% boxes around tokens
\let\NonterminalFont=\tenrm
\newbox\TStrutbox
\setbox0\hbox{\NonterminalFont{Bg}}
\setbox\TStrutbox\hbox{\vrule\wi0pt\he\ht0\de\dp0}
\def\TextStrut{\unhcopy\TStrutbox}
\def\HorzLine{\hrule \he \stroke \de 0pt}
\def\HFil{\leaders\HorzLine\hfil}
\def\HFill{\leaders\HorzLine\hfill}
\def\Nonterminal#1
{\setbox1\vbox to 0pt{
\vss
\hbox{\TextStrut\NonterminalFont\space#1\space\hskip-\stroke}
\vss}
\hbox{
\BoxStrut
\LeftSideArrow
\lower\irad\vbox{
\TopSquare
\copy1
\BotSquare}
\RightSideArrow}
}
\def\TopSquare
{ \hbox{
\vrule\he\stroke\de\irad\wi\stroke
\vrule\he\stroke\de0pt\wi\wd1
\vrule\he\stroke\de\irad\wi\stroke}
}
\def\BotSquare
{ \hbox{
\vrule\he\orad\de0pt\wi\stroke
\vrule\he\stroke\de0pt\wi\wd1
\vrule\he\orad\de0pt\wi\stroke}
}
\def\\#1{\Nonterminal{#1}\HFil}
\def\last#1{{\def\RightSideArrow{}\Nonterminal{#1}}}
!% piping
\def\foo{\rlap{\foofont\char'40}}
\def\foo{}
\def\FulVert{\vrule \wi\stroke\foo\hskip-\stroke}
\def\TopVert{\vrule\de-\irad \wi\stroke\foo\hskip-\stroke}
\def\BotVert{\vrule\he-\orad \wi\stroke\foo\hskip-\stroke}
\def\Center#1,#2.
{\hskip\radius\foo#1\lower.5\stroke\hbox{\pipefont#2}\hskip\radius}
\def\ru{\char'10\hskip -2\radius}
\def\rd{\char'11\hskip -2\radius}
\def\ld{\char'12\hskip -2\radius}
\def\lu{\char'13\hskip -2\radius}
\def\thru{\hskip-\radius\vrule\he\stroke\de0pt\wi2\radius\hskip\radius\hskip-2\radius}
\def\Center#1,#2.
{\foo\hskip\radius#1{\pipefont#2\unskip}\hskip-\radius}
\def\LT{\Center\BotVert,\lu.}
\def\LU{\Center\FulVert,\lu.}
\def\LL{\Center\FulVert,\ld.}
\def\LB{\Center\TopVert,\ld.}
\def\LMid{\Center\TopVert\BotVert,\rd\ru\thru.}
\def\LMU{\Center\TopVert,\rd\thru.}
\def\LML{\Center\BotVert,\ru\thru.}
\def\LFD{\Center\FulVert,\ru\thru.}
\def\LS{\Center\TopVert\BotVert,\rd\ru.}
\def\RT{\Center\BotVert,\ru.}
\def\RU{\Center\FulVert,\ru.}
\def\RL{\Center\FulVert,\rd.}
\def\RB{\Center\TopVert,\rd.}
\def\RMid{\Center\TopVert\BotVert,\ld\lu\thru.}
\def\RMU{\Center\TopVert,\ld\thru.}
\def\RML{\Center\BotVert,\lu\thru.}
\def\Cross{\Center\FulVert,\thru.}
\def\LR{\Center,\thru.}
\def\TB{\Center\FulVert,.}
!% ShiftBox
\newbox\x
\newbox\y
\newbox\tempy
\newbox\z
\newbox\tempz
\def\ShiftBox#1{
\savemod
\saverulebox
\setbox\x
\vbox{ \everycr{\noalign{{\modifyrulebox\global\setbox\z\hbox{}}}}
\halign{&\setbox\x\hbox{##}
\global \setbox\z\hbox{\unhbox\z\vrule\he\ht\x\de\dp\x\wi0pt}
\unhbox\x
\cr
#1}}%
\lower\ht\y\box\x\HFil
\restoremod
\restorerulebox
}
\def\saverulebox{
\setbox\tempy\box\y
\global \setbox\y\vbox{}
\setbox\tempz\box\z
\global \setbox\z\hbox{}
}
\def\restorerulebox{
\global \setbox\y\box\tempy
\global \setbox\z\box\tempz
}
\def\topmod{}
\def\thisrow{\global\let\modifyrulebox\firstmod}
\def\firstmod{
\global\setbox\y\vbox{\hrule\he0pt\wi0pt\de\dp\z}
\global\let\modifyrulebox\latermod
}
\def\latermod{
\global\setbox\y\vbox{\unvbox\y\hrule\he\ht\z\de\dp\z\wi0pt}
}
\def\savemod{
\let\tempmod\modifyrulebox
\global \let\modifyrulebox\topmod
}
\def\restoremod{
\global\let\modifyrulebox\tempmod
}
\DontIgnoreWhiteSpace
!{\baselineskip0pt
\lineskip0pt
\LeftToRight
\IgnoreWhiteSpace
\def\ms{\os\os\os\os}
\def\os{\omit\span}
\hbox{
\\{NIL}
\ShiftBox{
\ms\LT\\{bit}&\RT\cr
\ms\ShiftBox{
\ShiftBox{
\ShiftBox{
\LU\\{fixnum}&\RT\cr
\LU\\{bignum}&\RMU\thisrow\cr
}\\{integer}&\RML\thisrow\cr
\LU\\{ratio}&\RB\cr
}\\{rational}&\RT\cr
\ShiftBox{
\LU\\{short-float}&\RT\cr
\LU\\{single-float}&\RMid\thisrow\cr
\LU\\{double-float}&\RL\cr
\LU\\{long-float}&\RB\cr
}\\{float}&\RMid\thisrow\cr
\LU\\{complex}&\RB\cr
}\\{number}&\RU\cr
\ms\LU\\{standard-char}\\{string-char}\\{character}&\RU\cr
\LU\\{keyword}&\os\os\os\RML\\{symbol}&\RU\cr
\LU\\{null}&\os\os\os\LS&\TB\cr
\LMid\\{cons}&\os\os\RMU\\{list}&\RML\\{sequence}&\RMid\thisrow\cr
\os\LL\\{simple-vector}&\LML\HFil&\RML\\{vector}&\LS&\TB\cr
\os\LL\\{simple-bit-vector}&\LFD\\{bit-vector}&\RL&\TB&\TB\cr
\os\LL\\{simple-string}&\LFD\\{string}&\RB&\TB&\TB\cr
\os\TB&\os\LB\HFil\\{simple-array}&\RMU\\{array}&\RL\cr
\ms\LL\\{stream}&\RL\cr
\ms\LL\\{hash-table}&\RL\cr
\ms\LL\\{readtable}&\RL\cr
\ms\LL\\{package}&\RL\cr
\ms\LL\\{pathname}&\RL\cr
\ms\LL\\{function}&\RL\cr
\ms\LL\\{compiled-function}&\RL\cr
\ms\LB\\{random-state}&\RB\cr
}
\last{T}}}
\hbox{}
}\caption{This figure shows all required subclass relationships among the classes that\break
are instances of
standard-type-class, with the exception of classes defined by means of\break
defstruct. Implementations may choose to impose additional ones.}
\endfig
\endsubSection%{Types and Classes}
\endSection%{Classes}
\beginSection{Generic Functions and Methods}
A {\bit generic function\/} is a function object, which, when it is invoked,
is able to designate one out of a set of operations, depending on the
classes of its arguments. The generic function is said to
{\bit discriminate\/} on the classes of its arguments.
[The following is under discussion:
A generic function is a first-class object in the \CLOS.
It can be used as an argument to {\bf funcall} or {\bf apply} and
stored in the symbol-function cell of a symbol.]
[The following is under discussion: A generic function is created
using the function {\bf make-generic} or the
macro {\bf defgeneric}. The macro {\bf defgeneric} stores the generic function
in a specified symbol-function cell.]
The operations that are provided by a generic function are defined by
the methods associated with it.
A {\bit method\/} is a function object. It consists of two
parts: a set of argument
{\bit specializers\/} that is used to determine when it is applicable and a method
function.
%Methods are first-class objects in the \CLOS.
A method can be used as an argument to {\bf funcall} or {\bf apply} and
stored in the symbol-function cell of a symbol.
A method can be defined and associated
with a generic function by using {\bf defmethod} or {\bf add-method}.
[An issue under discussion is whether a generic function must be defined
before any methods can be added to it.]
When a generic function is invoked, the arguments specializers of its
associated methods are used to determine which method function is
invoked.
An {\bit argument specializer\/} is the name of a class or an
individual.
The class of each of the arguments passed to the generic function
is determined and the classes of the arguments are then
compared with the
argument specializers of each of the methods associated with the generic
function. The method function of the method with the most specific
set of argument specializers that are identical to or more general than
the classes of the arguments is invoked. The order in which differences
between the classes of the arguments and the arguments specializers are
considered is defined by the
{\bit argument precedence order\/} for the generic function. The relative
specificity of argument specializers is determined by the class lattice.
%The {\bf class precedence list} is used to determine
%which specializer is more specific.
Any individual is always more specific than any class. There
is a class named {\bf t} that is more general than any other class. When every
argument specializer in the set of argument specializers for a method is either
unspecified or {\bf t}, the method function for that method is called the
{\bit default method function\/} of the generic function.
%The precise definition for determining which method of a generic
%function to invoke will be given in section XXX.
\endSection%{Generic Functions and Methods}
\beginSection{Method Selection}
\endSection%{Method Selection}
\beginSection{Method Combination}
[To be written.]
We are currently working to integrate the programmatic ({\bf
run-super}) and declarative ({\bf define-method-combination}) method
combination techniques. The references to method combination throughout
this document will be further specified in a future draft.
%Methods can be combined by means of the {\bf run-super} construct.
%The {\bf run-super} construct allows a method to specialize a ``super''
%method.
\endSection%{Method Combination}
\beginSection{Meta Objects}
\beginsubSection{Metaclasses}
The {\bit metaclass\/} of an object is the class of its class. The metaclass
determines the form of inheritance used by its classes and
the representation of the instances of its classes. The metaclass mechanism
can be used to provide particular forms of optimization or to tailor
the \OS\ for particular uses (such as the implementation of other
object languages---like Flavors, Smalltalk-80, and Loops).
Any new metaclass must define the structure of its instances, how their storage
is allocated, how their slots are accessed, and how slots and methods are
inherited. The protocol for defining
metaclasses will be discussed in the chapter ``Meta-Object Protocol.''
\endsubSection
\beginsubSection{Standard Metaclasses}
The \OS\ defines a number of {\bit standard metaclasses}. These include
the following:
{\bf standard-type-class}, {\bf structure-class}, and {\bf class}.
The class {\bf standard-type-class} is a superclass of all the classes
that correspond to the standard Common Lisp types specified in
{\it Common Lisp: The Language\/} by Guy L. Steele Jr. except {\bf atom} and
{\bf common}. These types are listed in Figure~1-1.
This metaclass allows the special kind of class
inheritance rules that are needed to handle the classes that
correspond to the standard Common Lisp types.
It is not possible to make an instance
of a class whose class is {\bf standard-type-class} using the function
{\bf make-instance}.
%It is possible to define methods for built-in classes.
The class {\bf structure-class} is a subclass of {\bf standard-type-class}.
All classes defined by means of {\bf defstruct} are instances or
{\bf structure-class} or a subclass of {\bf structure-class}.
%The use of {\bf defstruct} implicitly defines a new class which is an
%instance of {\bf structure-class}.
%Instances of {\bf primitive-lisp-type-class} are classes that correspond
%to the basic Common Lisp types.
%While all classes that correspond to the types
%listed in Figure~1-1 must be instances of either {\bf structure-class}
%or {\bf primitive-lisp-type-class}, no implementation is {\it required\/} to
%have any class that is an instance of {\bf primitive-lisp-type-class}.
\endsubSection
\endSection
%\beginSection{Meta-Objects}
%Includes objects for classes, objects for methods, objects for generic functions.
%Use: efficiency in implementation; experimentation.
%Allows for variations in the representation of objects, the syntax of
%methods, the combination of methods.
%Can be used to provide tuning and optimization for a particular application.
%\endSection
\endChapter
\bye